This question is locked. New answers and comments are not allowed.
I have been attempting to leverage the "data-init", "data-show", etc... attributes for my views to execute specific functionality at specific view lifetime events. However, I ran into a snag when I attempted to execute the view-model method directly. It turns out that the context of "this" in the view-model's init method is not the view-model itself when called from the "data-init" attribute. For example, I created a "myViewModel" view-model that contains an "init()" function. If I define the associated view's data-init function as data-init="myViewModel.init()" the view-model's init function is called but the "this" context is some object other than the expected view-model. I also tried setting the "data-model" attribute to be "myViewModel" but this did not seem to help. I have been able to work around this issue by creating associated "onMyViewModelInit()" functions outside of the scope of the view-model which in turn calls the "myViewModel.init()" which gives "this" the proper context. However, this seems kind of hacky.
Also, concerning the view's lifetime events I am confused as to why the "before-show" event is executed prior to the "init" event. This seems backwards especially since the "before-show" event is executed prior to every "show" event but the "init" event is only ever executed on the initial creation of the view. I had expected that the event order would be "init" -> "beforeShow" -> "show" -> "hide" -> etc... but this is not the case. Any chance that these events will be re-ordered as described above? This would greatly simplify my view initialization logic. Also, is there an event defined for "destroy" or "kill" or anything similar to allow cleanup prior to deleting a view?
Also, concerning the view's lifetime events I am confused as to why the "before-show" event is executed prior to the "init" event. This seems backwards especially since the "before-show" event is executed prior to every "show" event but the "init" event is only ever executed on the initial creation of the view. I had expected that the event order would be "init" -> "beforeShow" -> "show" -> "hide" -> etc... but this is not the case. Any chance that these events will be re-ordered as described above? This would greatly simplify my view initialization logic. Also, is there an event defined for "destroy" or "kill" or anything similar to allow cleanup prior to deleting a view?
6 Answers, 1 is accepted
0
Hello Keith,
Jordan
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
Thank you very much for using Icenium, but you may get a faster and more accurate response from our Kendo UI Team and dedicated user feedback portal or forums.
We will still relay your post to them, but the response will be in Icenium forums that may not be the proper place where other users will benefit from it.
Jordan
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
0
Keith
Top achievements
Rank 2
Rank 2
answered on 28 Feb 2013, 05:57 PM
This may be a dumb question but how do I access the Kendo UI forums since I have never officially "purchased" a Kendo license? According to the Kendo site it states that you are required to have a license to access the forums.
0
Hi Keith,
About the context of the declarative initialization - this is how kendo.get works - it does resolve your callback, but it can't resolve the context, hence your this will be different. What you've already done is the correct way of handling it.
The event lifecycle of Kendo UI Mobile is indeed wrong and before-show should be fired after the init event. We've logged it as an issue and will fix it for the next releases. I've updated your points for the report. As for a destroy event - we do not auto destroy the Views in Kendo UI Mobile - you can use the destroy method to do so and of course you can clean the View up before calling it. Do have in mind that the Kendo UI destroy method will call the destroy methods of any Kendo Widgets it can find in itself, so you don't need to destroy them all.
As for Kendo Forums - the license that comes with Icenium doesn't include a support option, which is required to be able to post in the Kendo Forums. You can read there or post your questions in Stack Overflow with a kendo-ui tag. More information is available in the Forums FAQ.
Regards,
Kamen Bundev
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
About the context of the declarative initialization - this is how kendo.get works - it does resolve your callback, but it can't resolve the context, hence your this will be different. What you've already done is the correct way of handling it.
The event lifecycle of Kendo UI Mobile is indeed wrong and before-show should be fired after the init event. We've logged it as an issue and will fix it for the next releases. I've updated your points for the report. As for a destroy event - we do not auto destroy the Views in Kendo UI Mobile - you can use the destroy method to do so and of course you can clean the View up before calling it. Do have in mind that the Kendo UI destroy method will call the destroy methods of any Kendo Widgets it can find in itself, so you don't need to destroy them all.
As for Kendo Forums - the license that comes with Icenium doesn't include a support option, which is required to be able to post in the Kendo Forums. You can read there or post your questions in Stack Overflow with a kendo-ui tag. More information is available in the Forums FAQ.
Regards,
Kamen Bundev
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
0
Hello Keith,
I would like to follow up on the beforeShow/init event sequence decision. Its current state is counter-intuitive indeed; it is implemented this way so that the view element is visible by the time the init event is triggered. A lot of existing customer code relies on that for sizing/dimensions related code - there are certain third party widgets which experience problems if initialized and rendered in a hidden element.
The beforeShow event is usually used for authorization interception, as calling the preventDefault method on the event parameter stops the view from displaying. Of course, this event is triggered before the view element is visible.
Given that, moving the init event before the beforeShow event would result in a breaking change (init being triggered while the view element is still hidden). Such change is going to be hard to work-around for people relying on the current state.
Can you elaborate a bit on how does the current event order complicates your case? Perhaps we can figure out an improvement which can facilitate your scenario better without introducing breaking changes.
Thanks in advance,
Petyo
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
I would like to follow up on the beforeShow/init event sequence decision. Its current state is counter-intuitive indeed; it is implemented this way so that the view element is visible by the time the init event is triggered. A lot of existing customer code relies on that for sizing/dimensions related code - there are certain third party widgets which experience problems if initialized and rendered in a hidden element.
The beforeShow event is usually used for authorization interception, as calling the preventDefault method on the event parameter stops the view from displaying. Of course, this event is triggered before the view element is visible.
Given that, moving the init event before the beforeShow event would result in a breaking change (init being triggered while the view element is still hidden). Such change is going to be hard to work-around for people relying on the current state.
Can you elaborate a bit on how does the current event order complicates your case? Perhaps we can figure out an improvement which can facilitate your scenario better without introducing breaking changes.
Thanks in advance,
Petyo
the Telerik team
Share feedback and vote for features on our Feedback Portal.
Want some Kendo UI online training - head over to Pluralsight.
0
Keith
Top achievements
Rank 2
Rank 2
answered on 04 Mar 2013, 01:14 PM
Thanks for the heads up on the Stack Overflow forums... I will start using them.
0
Keith
Top achievements
Rank 2
Rank 2
answered on 04 Mar 2013, 01:16 PM
It may just be that it is counter intuitive but it would be helpful to me if in the before-show function I could know whether or not the init function was going to be called next. This would help me manage my view startup / initialization code so that I could take the appropriate action based on whether the view is being initialized or just being re-shown.