-
1. Re: Return data from resource triggered script
You cannot return a resource and expect that to be returned to the client, a resource object is not a valid response. Currently the only response you can construct in the scripts is an error response. LIVEOAK-691 has been created so that we will throw an error when an unknown response is encountered to make it more clear that something is wrong.
It is designed this way. You shouldn't be using resource triggered scripts to be returning something other than what was requested. For that, I would say you should use a script which exposes an custom endpoint, but we do not have that functionality yet (its planned for some future release, but not any release in particular). Resource triggered scripts should be used for more manipulating either the request or the response or denying access for a particular request.
If you could explain what you are trying to do with your script we may be able to help you better?
From the above script, it looks like you are trying to only return only one member from a collection. For this its much easier to write a script to take the incoming request and apply the 'limit' parameter to it. This will send the limit parameter to the resource and the resource itself will only return the one element.
function preRead(request, libraries) {
request.context.parameters.limit=1;
}
The common parameters are offset, limit, fields and sort. So if you wanted to only return the 2nd and 3rd elements in a collection, sorted by name, where the only fields you want of the child members are 'name' and 'text'. Then you would do something like:
function preRead(request, libraries) {
request.context.parameters.limit=2;
request.context.parameters.offset=1;
request.context.parameters.put("sort", "name");
request.context.parameters.put("fields", "*(name,text)");
}
[Note: technically you should be able to do request.context.parameters.sort="name" and request.context.parameters.fields="*(name, text)" but it looks like there is a bug somewhere with that. It should be fixed for the next release.]
Of course, for the above request, its probably better for your client to be adding the limit,offset, sort and fields themselves in the request. But for this example, it shows how you can read and change those values if you some reason you want to enforce certain restraints for them.
-
2. Re: Return data from resource triggered script
Thanks for the reply Matt! Essentially I want to pass an ID to a server-side script and return a single object. So far with this code:
var resources = client.read('/chat/storage/chats', {
"q" : "{'chatId': '3'}",
"fields" : "*(*)"
});
I have been able to use print(resources.length) to verify that only one resource was returned. Now I am hoping that I can just return the one resource object returned from client.read(...) to the requesting liveOak.readMembers(...) success function. The more I read through discussions and documentation. I'm feeling like this isn't possible right now. Is this true. Do I have any other options?
-
3. Re: Return data from resource triggered script
ok, so can you please verify if this is what you are trying to do: when a client does a GET on /chat/storage/chats you want to return the results as if the client had done a GET on /chat/storage/chats?fields=*(*)&q={'chatId':'3'} instead
And I am assuming for some reason the client can't just ask for that URL directly, otherwise it makes much more sense to have the client directly just add these parameters themselves.
If its the case where the script needs to add these parameters, please look at my previous post which explains how to use scripting to add these parameters (offset, limit, fields, sort, q, etc). You shouldn't be using the client if this is what you want to do.
If this is not the exact use case you are after, can you please explain exactly the endpoint the client tries to access and the different results you are expecting to be returned?
We may be missing a usecase that should be covered. Currently I do not understand why the clients don't just specify the parameters themselves, or why adding the parameter in the script is not sufficient.
-