I think you are making this harder on yourself than necessary.  The tree already supports populate on demand inherintly, you do not need to code anything client-side to get this to work.  In fact it will automatically detect when the browser doesn't support the client callback and utilize postbacks instead.  You will code both the same way.  To see how this works I suggest looking at http://webcontrols.dotnetnuke.com/DNNTree.aspx

You can get the full source code for this sample from the WebControl download page.

If you feel you want to go the custom-script route I suggest that you start by looking at the unit tests I have defined for the tree on the ClientAPI documentation page.

On a side note it looks like your existing page script does not account for the fact that when your controls are placed in a naming container (user control) their client-side IDs are prefixed.

If you are planning on using the built in populate on demand of the tree, you are not in control of what gets passed in the callback.  If you decide to perform your own callback you are allowed to pass anything you want in the single argument for the callback (you need to serialize it yourself).  I am copying in a section of the callback documentation that relates to this.

Closing Thoughts

During the development of the client callbacks I found myself asking the question, “Should the developer have to be responsible for packing/serializing multiple arguments on the client, then have to unpack them on the server to process?”  For a short time I was writing a xmlrpc namespace to handle this type of serialization, but found myself backing away for two reasons.

1.       I wanted to implement an existing technology and keep it as close to the ASP.NET 2.0 implementation as possible.

2.      A protocol such as XMLRPC or SOAP are responsible for Remote Procedure Calls/Accessing Objects, which doesn’t quite fit into what the ASP.NET callback is about.  We are not creating and invoking any object on the server.  Rather we are invoking a particular method on the server with a defined contract, thus reflection is not necessary.

Those two reasons are not going to prohibit me from implementing a more elegant solution to tackle the serialization problem, but I feel that anything added needs to supplement this “simple” implementation.  Hence the CallBackType=Simple in the ClientAPICallBackResponse object.