beforeRender and afterRender
#1
Posted 28 May 2012 - 08:53 AM
#2
Posted 28 May 2012 - 11:21 AM

#3
Posted 28 May 2012 - 12:29 PM
Use case:
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.
I've also developed a 'social' module which uses the afterRender event toadd more fields to the 'Edit profile' view.
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
#4
Posted 28 May 2012 - 01:40 PM
My extensions:
ActiveResource for Yii - the RESTful equivalent to ActiveRecord | Neo4Yii - wrapper for the Neo4j graph database | EPhpThumb - a simple, lightweight wrapper for the phpThumb library
Get social:
Circle me on Google Plus
Follow me on Twitter
#5
Posted 28 May 2012 - 02:43 PM
http://www.yiiframew...fied-meta-tags/
http://pastebin.com/mC9qsRMS
http://www.yiiframew...other-approach/
#6
Posted 28 May 2012 - 08:02 PM
That's probably because I come from CakePHP..
What is the alternative?
#8
Posted 28 May 2012 - 11:58 PM

#10
Posted 29 May 2012 - 04:01 AM
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.
#11
Posted 29 May 2012 - 05:23 AM
#12
Posted 29 May 2012 - 05:46 AM
Yeah, with beforeAction, I really can't think of any use for beforeRender.
#13
Posted 27 June 2012 - 11:51 AM
- 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.
Danke.
#14
Posted 27 June 2012 - 12:21 PM
www.ramirezcobos.com
www.yiianswers.com
www.2amigos.us
www.getyiistrap.com
www.github.com/tonydspaniard
www.github.com/2amigos
#15
Posted 29 June 2012 - 03:58 AM
It's just confusing and cluttering up the core.
#16
Posted 29 June 2012 - 04:26 AM
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.
#17
Posted 29 June 2012 - 04:42 AM
jacmoe, on 29 June 2012 - 03:58 AM, said:
It's just confusing and cluttering up the core.
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.
#18
Posted 19 November 2012 - 04:56 PM
qiang, on 28 May 2012 - 08:53 AM, said:
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
#19
Posted 06 December 2012 - 10:21 AM
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.
#20
Posted 27 January 2013 - 12:38 PM

Help

This topic is locked















