several different samples for Menu component are broken

[adriatic]

Direction sample: attempt to change any of the provided settings (green rectangle):

The menu object gets rendered as a single line (likely weight is set to 0):

The same is true for Orientation sample and Animation sample

[JeroenVinke]

The problem here has to do with inconsistenties in destroying Kendo controls. Take a look at the official example to destroy a grid. You have to empty out the HTML of the grid, before you recreate it again, otherwise you'll see things like double grid headers and other weird things.

Which is fine if the grid uses a datasource as it would simply take the data out of the datasource and rerender the grid. But when you use the grid like this the grid will be emptied, including the HTML you had defined initially. So for some controls, used in certain ways, you need to empty out the control before recreating it, yet for other controls (or the same control used in a different way) you definitely don't want to clear out the control.

I have thought about cloning the HTML inside the wrapper (on initialization) and storing it somewhere, and using that HTML again when you recreate the control. But since that HTML won't be updated when you are using the control, you'll end up with a different representation of the control when it gets recreated. The best solution might be to expose the destroy logic, e.g. you have to opt-in to empty out the widget.

Of course all of this wouldn't be necessary if there was a way to change the orientation without recreating the control.

[adriatic]

This is a rather unpleasant situation and it should become a part of the future discussion with Telerik on how to improve KendoUI API.

I am assuming that you used Grid examples as illustration because it is the most inconvenient case of the problem I introduced above and that the same reasoning applies in this case as well. I noted the following sentence from KendoUI API document, explaining when the widget has to be destroyed and recreated in order to accommodate a request for change

The widget settings and behavior must be drastically changed, which cannot be achieved through the available API methods.

Since they specifically expose the change of the orientation of the toolbar in their sample, I am remain baffled why did they not provide the needed API. In addition, I am puzzled why is it that I found this only yesterday.