Hello Simon Wolters,
The reason that we introduced this action log is simply to save performance from constant post-back (where needed), batching the action execution in a single less often post-backs.
What is meant by "where needed":
- Imagine, that you have a panelBar with just 3 root elements. And there is no unique identification for any of them (no value, text etc. that you can rely on its uniqueness), only the position makes it unique. What if, on the client you do the following:
1. Delete Item0;
2. Change the name of Item1 to the one previously possessed by Item0;
4. On the server, how can you determine, what happened?
There isn't a way to do so and this is example scenario, where this functionality is needed. That's why you can log the actions and then execute them on the server, making possible for you to know which element is which element.
Now, you need to apply the Expanded state to your data-model. You know the structure of items, because you executed (read) the log. All you need to do, in order to apply the Expanded state (and what I meant, by "you don't need the entire history of expand/collapse" is that your model, doesn't possess the different stages of the history, right? It only keeps the current state), you need only to directly look at the current state (again, you know the structure: firstNode->deleted=>firstNodeModelEntity->deleted; secondNode->becomesFirstNode=>firstNode=secondNode; firstNode.Name="...." and so on, and so on. And finally, what is the firstNodeModelEntity.Expanded=firstNode.Expanded).
After all, there is chance that I didn't understood your scenario correctly. Please, if this is the case, explain it in a bit more detail for me and I will do my best to help you resolve the problem!
Hope this is helpful for you!
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Public Issue Tracking
system and vote to affect the priority of the items