To All,
I have seen significant discussion regarding DemandLoad and a little on callbacks initiated by a WebTree NodeClick.
I have wired the NodeClick as such:
protected override void OnInit(EventArgs e) { base.OnInit(e);tvUnitNavigator.NodeClicked += new NodeClickedEventHandler(tvUnitNavigator_NodeClicked); }
{
base.OnInit(e);tvUnitNavigator.NodeClicked += new NodeClickedEventHandler(tvUnitNavigator_NodeClicked);
}
and created a NodeClicked handler (sort of dumb, just to test):
protected void tvUnitNavigator_NodeClicked(object sender, WebTreeNodeEventArgs e) { Node blah = e.Node; }
Node blah = e.Node;
I was hoping to save the clicked Node's DataKey to a Session variable for use in a different form. So, the only server side processing will be to save the node to a Session variable - that is, I really don't want to change the tree and/or rebuild the tree.
Is there a simple solution???
Hello,
I think the solution would be to use custom javascript that would redirect to the infra after the AJAX update with WARP (e.g. do that in the NodeClick event handler).
Registering javascript that would execute after WARP update from the server is discussed here (includes using Literals)
http://forums.infragistics.com/forums/p/15748/57973.aspx#57973
Changing the URL of an IFrame is discussed here:
http://www.velocityreviews.com/forums/t84424-iframe-url-changing.html
HTH,
Rumen,
I was actually trying to use that to my advantage now that I have begun to understand the WARP pannel...
What I think can be done (but don't know how) is to set some session variables in the NodeClick event and then trigger the loading of a form in a frame. The actual loading of the form would not have any parameters in the QueryString. The form would take its defining parameters (a record GUID) from the session variable updated in the NodeClick event.
Don't know if it can be done, but am getting closer...
Hello Roger,
The problem is that TargetFrame and TargetUrl are working in one mode (with the NavigateUrl property) while postback events are working in another mode that is not compatible with these properties (NodeClick event on the server).
Request.QueryString works with mode #1, while the more secure one is mode two. Still, after postback I am not quite sure how to switch to another iframe. Maybe you can register javascript in the NodeClick event handler using Page.ClientScript.RegisterStartupScript that would do something like this - like startup javascript that would take care of that.
Thank Rumen,
I have got the tree in a WARP panel now and am playing with it. I have trapped the WebTree events and most seem to work.
The problem I am running into is that I am trying to avoid sending across the Request.QueryString potentially insecure data that would give a chap the GUID to a record - which could then be used to access data directly. I want to save the node to a Session variable at the NodeClick event. Then I want to transfer control to another frame using another form. I set the TargetFrame and TargetUrl properties in the nodes collection, but the WebTree seems to transfer control to the TargetUrl in the TargetFrame before the NodeClick is executed.
At that point I do not have the clicked Node saved to the Session variable.
Is there an algorithm or process to use the NodeClick event to transfer control to another form in another frame???
It is a good question. Unfortunately there is no easy solution for that, as far as SmartCallBacks are used (both Automatic and Manual). The idea is that the nodes that come on demand from the server do not really exist on the server-side part of the treeview (hence the performance boost and the ability for the treeview to not refresh). This however comes at a cost - postback events like NodeClick are not supported for nodes that come on demand.
One possible approach to deal with that would be to hook client-side events from CSOM and in the Before...Click event for example, to store some Node specific value in a hidden field (say, DataKey / DataPath / Text, etc) and then on postback to use that to get the actual node on the server and reconstruct the tree. It will require some coding, but unfortunately is the only way to go with SmartCallBacks.
Basically, it is a trade-off between speed and flexibility. To gain super-speed of the SmartCallBacks functionality we sacrifice some flexibility (but then again, we do provide the Manual / Automatic modes (without Smart)) that should be helpful in this case.