Currently trying to use the headless client plugin like so:
oClient.queueMethod(null,'ride', [oArg],
function (event)
{
var nRun = aRun[i];
var oLocalClient= oClient;
// some code
aReady.push(oLocalClient);
});
It’s inside of a loop for aRun.
What I’m trying to do is curry in some of the values I need in my callback function.
To my great surprise however, I’m getting the following exception thrown:
java.lang.IllegalArgumentException: Method/Function is not a servoy method
A quick dive into the headless client plugin code reveals the following:
final FunctionDefinition functionDef = new FunctionDefinition(notifyCallBackMethod);
I can only assume that FunctionDefinition can only accept Servoy methods. Is this something I can hope to overcome with a little tinkering, or am I out of luck on this front?
James,
No, you need to define a (form or global) method in your solution for the callback.
The plugin just uses the form name (if not global) and the method name and calls this when the remote method is done.
We cannot use the js function object because the context in which it is defined may haven been lost already when the call is made.
Rob
I was under the impression that the whole point of currying was that the scope of the defined method was saved, regardless of where you passed it around to. That being said, that’s all really just theory, if the Servoy backend doesn’t have that implemented in a way that lends itself to that, then that’s fair enough I suppose.
I guess my main problem is that there’s no consistent way of know which headless client is returning into the callback. If I have 4 HLC performing the same work on different sets of data, all calling back to the the callback, I really need a way to know which one is coming back.
Obviously if everything works out fine then I can include the clientid in whatever I return. However, if there is an exception, all I get back is an even with an exception message, and have no way to know what needs to be done again.
Any ideas?
we only store the name of the form and the name of the method in the callback. Thats all the “scope” we have
Because you could have a client that spawns a headless client and gives it a callback method
But that callback method is called 1 hour later when it is done.
In the mean time that whole form could be destroyed so the whole context when you created the headless client and the callback is completely gone
But because we only store the name strings of what we want to call we recreate the form and its context and then call that new method (which is not the same instance as before)
For a normal call you can just give back a return value from the server yes, to know which one it was. (you could even give that value to the method you are calling so that it just returns the given value)
But for an error you dont get that.
You could create a form method per client… But if that is completely dynamic then that can be a problem.
What we could do is return the JSClient object in the 2 callback methods as the last parameter…
you can do this quickly your self
open the source (thats inside headlessclient.jar) of JSClient.java
line 102 is this:
functionDef.execute(plugin.getPluginAccess(), new Object { event }, true);
make it
functionDef.execute(plugin.getPluginAccess(), new Object { event ,JSClient.this}, true);
and line 120 (exception handling)
functionDef.execute(plugin.getPluginAccess(), new Object { event }, true);
make it
functionDef.execute(plugin.getPluginAccess(), new Object { event , JSClient.this}, true);
then you have to compile and sign it again (make quickly your own certificate)
That sounds like a great idea! Thanks Johan. ![Very Happy :D]()
Is there an SVN somewhere I can pull the code off of, or should I just unbundle it all from the jar?
Hi James,
I think you’ll want to read a bit here: http://wiki.servoy.com/display/DOCS/Open+Source+Guide
Paul
Thanks guys!
Now I can do some real damage ![Twisted Evil :twisted:]()