Home - Forums-.NET - FlyTreeView (ASP.NET) - PopulateOnDemand

FlyTreeView (ASP.NET)

Technical support and KB related to the FlyTreeView control

This forum related to following products: FlyTreeView for ASP.NET

PopulateOnDemand
Link Posted: 02-Feb-2008 02:49
My main problem on using 'Populate On Demand' is, when I using this method, ViewState that contains all the structure and data of treeview moves between client and server 2 time per request.



When I use PopulateNodesOnDemand, after selecting each node, all the loaded viewstate in client, sent back to the server and load again with new treeview structure and data into the client.



Is there any other method to send just the node which needs to be loaded to the server and receive, only that much of data that needed to create children of the selected node?
Link Posted: 02-Feb-2008 03:14
[quote="al_kino"]My main problem on using 'Populate On Demand' is, when I using this method, ViewState that contains all the structure and data of treeview moves between client and server 2 time per request.

What do you mean "2 times"?  Is it to and from server (2 times in total)?
AFAIK, ASP.NET callback does not send viewstate from server within callback response - only response data.

During the callback, a control needs to "know" and restore all of its previous vewstate. This is a common ASP.NET callback rule.
FlyTreeView, in addition, sends all of its client-side changes (loaded nodes, expand/collapse actions log) to make server-side treeview exactly reflect client-side one with all its loaded nodes and changes (though D&D, client API, etc.).
There're no built-in way to skip this step.

Anyway, there's an alternative approach. Similar to what we had in ASP.NET 1.1 version of the control (to replace callback lack). But this approach will require some client-side scripting.
Anyway I'll describe the idea in brief:
You can handle client-side "expanded" event and perform custom XmlHttpRequest to a custom ASP.NET handler, which will produce required response (JSON-encoded nodes data). So you'll be able to handle this response, create client-side nodes from it and add them to a desired location.
This looks like a hack, but so far this looks like the only way to avoid viewstate transfers.