Telerik blogs

In my previous blog post I told you how the Web Service load on demand mode of RadTreeView delivers the best performance. A logical question arises - why we have the other load on demand modes (server side postback and callback) if they do not perform on par with the Web Service mode. The answer is not that obvious. The truth is every load on demand mode has its pros and cons. The following table describes visually the load on demand modes according to three criterions - performance, templates support, ease of implementation.

  Performance Templates Support
Ease of Implementation
Web Service fullfullfullfullfull halfhollowhollowhollowhollow fullfullfullhollowhollow
Server Side Callback fullfullhollowhollowhollow fullfullfullhollowhollow fullfullfullfullhollow
Server Side PostBack fullhollowhollowhollowhollow fullfullfullfullfull fullfullfullfullfull

And now lets delve into more details.

Web Service


The Web Service load on demand mode is the undisputed champion in terms of performance. It does not execute the page lifecycle, does not send the ViewState to the server and outputs tidy JSON which saves precious traffic.


The Web Service load on demand mode completely disregards the template set for RadTreeView (read as "templates don't work at all"). The reason is simple. Since only JSON is sent back and forth the actual template contents (controls and HTML that is) are lost. RadTreeView utilizes its client-side rendering abilities to convert the JSON returned from the web service into HTML representation of tree nodes. A possible workaround is to use ASP.NET Ajax 4.0 templates. Check here for a sample project and running demo.


I won't say that implementing a Web Service method is hard but it is not as easy as subscribing to a server-side event (NodeExpand).

Server Side Callback


Server Side Callback mode comes second here. Using ASP.NET 2.0 Callbacks involves sending the ViewState of the page back to the server. The page life cycle is executed as well. The good thing is that only a small portion of HTML is returned - only the nodes added during the NodeExpand event.


Server Side Callback mode supports templates with one limitation. It does not support any controls with client-side behavior (e.g. other RadControls for ASP.NET Ajax). You can use anything else though - static HTML, text boxes, buttons etc.


Somehow it feels easier to subscribe to an event and create RadTreeNode objects than implement a web service. A good think to know when using Server Side Callback mode is that only the expanded RadTreeNode will be updated after the load on demand request finishes. If you update any other control in the page the changes will not be applied (rendered).

Server Side PostBack


The Server Side PostBack mode has worst performance without any doubts. The page is posted back and as a result all controls are rendered and updated. A possible workaround is to wrap the RadTreeView control inside RadAjaxPanel or UpdatePanel. Then only the RadTreeView control will be updated. Still performance will be worse than other load on demand modes because the whole RadTreeView control will be rendered and updated.


Full support for templates with no limitations.


As with the Server Side Callback mode the user should subscribe to the NodeExpand event and add child nodes to the currently expanded node. A side effect from the full postback is that the developer can update other controls in the page (provided RadTreeView is not wrapped inside RadAjaxPanel/UpdatePanel).


I hope this helps.

About the Author

Atanas Korchev

 is Team Leader in Kendo UI Team

Related Posts


Comments are disabled in preview mode.