Sorry, I'm late jumping back into this thread. Thanks to Jim for pointing
out the thread activity.
I'm somewhat confused by the Java discussion. The whole point of my JSRS
remote scripting library was to obviate the need of a Java applet as used by
Microsoft's Remote Scripting. If you use JSRS, you need no Java at all on
the client side. You only need Java on the server side if you are using
Java as the server platform.
Also, while you can modify JSRS to use a DynLayer as a container, I'm not
sure why you should need to, since the library is designed to insulate you
from the implementation. Its use is based on making simple Remote Procedure
Calls and providing callback functions. Perhaps my lack of DynAPI
experience is showing - am I missing something? If LoadPanel doesn't do
what is necessary, I'm not understanding why one would need to break into
the otherwise working black box at all just to bring its hidden internals
into the DynAPI picture.
All you have to do on the client side is is include the library at the top:
<script language="javascript" src="jsrsClient.js"></script>
Then the syntax is:
jsrsExecute( pageContainingFunction, callbackToExecuteOnReturn,
functionName, strParameter)
or
jsrsExecute( pageContainingFunction, callbackToExecuteOnReturn,
functionName, arrayOfStrParameters)
Have a look at http://www.ashleyit.com/rs/jsrs/test.htm - the call to get
the server's environment variables is:
function envVar(){
jsrsExecute("test_rs.asp", myCallback, "envVar", "ALL_HTTP");
}
which uses this callback function:
function myCallback( returnstring ){
alert(returnstring);
}
I must not grok the full implications here if somehow it is more complicated
than that.
- Brent -
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
