Toolbar remains when scheduler is .destroy():ed.

[100%]

On

http://demos.telerik.com/kendo-ui/web/scheduler/index.html

if you open the firefox console and executes this script:

$("#scheduler").data("kendoScheduler").destroy();

the scheduler is almost destroyed, but the toolbar remains.

[100%]

Seems like adding this line

that.element.empty();

at the end of the function

destroy

(the 3rd search hit when searching for "destroy: function()" in kendo.scheduler.js)

is a possible fix.

[Rosen]

Hello,

The destroy method of the widget does not remove it from DOM by design. It is responsibility of the developer to remove it after the destroy method is called.
Note that some of the child/attached elements may be removed automatically during the destroy routine, however the main element/wrapper will not be removed.

Regards,
Rosen
Telerik

[100%]

But I am not referring to the widget as such, just the contents of it.
The expectations I have from a call to .destroy() is that the element gets into a state it was as before initializing a kendo scheduler on it. Blank.

[100%]

Or to phrase it in another way, having a div, calling

$('#thediv').kendoScheduler(init_obj);
$('#thediv').data('kendoScheduler').destroy();

and later

$('#thediv').kendoScheduler(init_obj);

should not end up in a scheduler with two toolbars.

[Rosen]

Hi,

I'm afraid that this is not the case. As stated in the documentation the destroy method does not remove the DOM but only prepares it for removal. Therefore, you as developer should clear the DOM after the call to destroy.

Regards,
Rosen
Telerik

[100%]

If I with a div like this:

<div id="thediv"></div>

run this:

$('#thediv').kendoScheduler(init_obj);
$('#thediv').data('kendoScheduler').destroy();

I expect the div to look like this afterwards:

<div id="thediv"></div>

[Rosen]

Hi,

As I have already mentioned this is not the designed behavior of the destroy method. You will need to clear the DOM manually.

Regards,
Rosen
Telerik

[Kevin]

I am having the same problem using a calendar inside a kendo View. 

From the documentation:
http://docs.telerik.com/kendo-ui/framework/widgets/destroy

Removes autogenerated HTML content, which is outside the widget, e.g. detached popups, dropdowns, etc. The main widget HTML remains intact and if needed, it should be removed from the DOM manually. The Window widget is an exception, as it represents a detached popup on its own.

The toolbar isn't considered part of the auto-generated content outside of the widget? That's the point hes making... it should return to the original state of the HTML. It's not that I disagree with what you're saying, but it's concerning that you don't seem to understand why the documentation could be misleading. 

Why didn't you include a simple example in your response? It's clear that we read the documentation and still struggled. 

[Rosen]

Hi Kevin,

I'm afraid that the toolbar is not outside of the scheduler widget. It is rendered within the scheduler wrapper element and it is part of its main content.

The "autogenerated HTML content, which is outside the widget, e.g. detached popups, dropdowns, etc." are exactly what the documentation said - detached elements like popups, dropdowns which are generated by the widget, thus the developer does not have control or knowledge where they are located in order to manually remove them from the DOM tree. For example such autogenerated widgets in the context of Scheduler is the popup events editor, or the toolbar calendar used for navigation.

Regards,
Rosen
Telerik

 

 

[Frederic]

I re-open that (very) old thread!

Because I just got the same issue and I can't believe that a destroy does not returns the DOM item to its original state.

As the actual version, we must add this, after destroying scheduler: 

$scheduler
.empty()
.removeClass("k-widget k-scheduler k-floatwrap")
.removeAttr("data-role role aria-multiselectable");

And, you understand that this is variable and can change from version to version when we update kendo. 
But, a simple "destroy" is invariable to every kendo version.

May I suggest to add an optional parameter to the destroy function, to require to also reset DOM to its original state?

We have single-page application, and we move from Scheduler to Grid, and to keep the DOM footprint as low as possible, we need to destroy it when we don't see it.  But, the original DOM source of the scheduler remains, allowing us to re-use it later to re-create the scheduler on-demand.

Look at this example, with Create / Destroy / Clean buttons.

https://dojo.telerik.com/@foxontherock/IXoxEceJ

 

[Martin]

Hello Frederic,

Thank you for the example.

Could you please try calling empty() method on the #scheduler element? That is because the destroy method removes the component, and there might be some HTML that is left from the initialization of the Scheduler. It appears to be working correctly now. Here is the modified example for reference.

Let me know how that works for you.

Regards,
Martin
Progress Telerik