How I can obtain all the responseId from a survey in Qualtrics using the API.
I don't want to download a file with the data, I just want to save the responseId in a object.
It is possible? I am looking in the API, but not finding anything.
Thanks in advance.
Sadly, there is no way to do exactly that.
I would use the file export with a few options to make your life easier.
First,
POST /surveys/{surveyId}/export-responses
{
"format": "json",
"compress": "false",
"embeddedDataIds":[],
"questionIds":[],
"surveyMetadataIds":[]
}
Then GET /surveys/{surveyId}/export-responses/{exportProgressId}
you get that ID from the previous request. You can call this function in a loop until it is done. It should be pretty fast, though, if you pass in the empty arrays in the previous step.
Then GET /surveys/{surveyId}/export-responses/{fileId}/file]
It should come back as fairly usable JSON, though it's not exactly what you wanted. It will have the response Ids on it plus some other data you probably don't want.
There should be a JSON object with a key called "responses", which is an array of objects that each have a key called "ResponseId"
Related
I wanted to create a new option in the Data Browser (just like the "username", "password", "authData"...fields), to hold a monetary value for my game. So a new field called "money" that will hold a value.
However, I'm not exactly sure how to go about doing so.
I took a look at the documentation and found things like .add but I wasn't sure exactly what was going on in the code.
Does anyone know a way to do this?
In the data browser, there is a "+ Col" button which allows you to add another field to your class. You can then set the name of the field and it's type.
You can also do this from their SDK's by simply setting the field, even if you have not added it via the data browser.
Here is what the Parse docs say regarding this:
Storing data through the Parse REST API is built around a JSON encoding of the object's data. This data is schemaless, which means that you don't need to specify ahead of time what keys exist on each object. You simply set whatever key-value pairs you want, and the backend will store it.
Source: https://parse.com/docs/rest#objects
I have a simple problem I need to solve, and list functions are my current attempt to do so. I have a view that generates almost what I need, but in certain cases there are duplicate entries that make it through when I send in edge-case parameters.
Therefore, I am looking to filter these extra results out. I have found examples of filtering, which I am using (see this SO post). However, rather than generate HTML or XML or what-have-you, I just want a regular ol' view result. That is, the same kind of object that I would get if I queried CouchDB without a list function. It should have JSON data as normal and be the same in every way, except that it is missing duplicate results.
Any help on this would be appreciated! I have tried to send() data in quite a few different ways, but I usually get that "No JSON object could be decoded", or that indices need to be integers and not strings. I even tried to use the list to store every row until the end and send the entire list object back at once.
Example code (this is using an example from this page to send data:
function(head, req) {
var row; var dupes = [];
while(row=getRow()) {
if (dupes.indexOf(row.key) == -1) {
dupes.push(row.key);
send(row.value);
}
};
}
Lastly, I'm using Flask with Flask-CouchDB, and I'm seeing the aforementioned errors in the flask development server that I'm running.
Thanks! I can try to supply more details if need be.
Don't you need to prepend a [, send a , after each row value except the last, and end with ]? To actually mimic a view result, you'd actually need to wrap that in a JSON structure:
{"total_rows":0,"offset":0,"rows":[<your stuff here>]}
Scenario:
I have a Board model in my Rails server side, and an Android device is trying to post some content to a specific board via a POST. Finally, the server needs to send back a response to the Android device.
How do I parse the POST manually (or do I need to)? I am not sure how to handle this kind of external request. I looked into Metal, Middleware, HttpParty; but none of them seems to fit what I am trying to do. The reason I want to parse it manually is because some of the information I want will not be part of the parameters.
Does anyone know a way to approach this problem?
I am also thinking about using SSL later on, how might this affect the problem?
Thank you in advance!! :)
I was trying to make a cross-domain request from ie9 to my rails app, and I needed to parse the body of a POST manually because ie9's XDR object restricts the contentType that we can send to text/plain, rather than application/x-www-urlencoded (see this post). Originally I had just been using the params hash provided by the controller, but once I restricted the contentType and dataType in my ajax request, that hash no longer contained the right information.
Following the URL in the comment above (link), I learned the how to recover that information. The author mentions that in a rails controller we always have access to a request variable that gives us an instance of the ActionDispatch::Request object. I tried to use request.query_string to get at the request body, but that just returned an empty string. A bit of snooping in the API, though, uncovered the raw_post method. That method returned exactly what I needed!
To "parse it manually" you could iterate over the string returned by request.raw_post and do whatever you want, but I don't recommend it. I used Rack::Utils.parse_nested_query, as suggested in Arthur Gunn's answer to this question, to parse the raw_post into a hash. Once it is in hash form, you can shove whatever else you need in there, and then merge it with the params hash. Doing this meant I didn't have to change much else in my controller!
params.merge!(Rack::Utils.parse_nested_query(request.raw_post))
Hope that helps someone!
Not sure exactly what you mean by "manually", posts are normally handled by the "create" or "update" methods in the controller. Check out the controller for your Board model, and you can add code to the appropriate method. You can access the params with the params hash.
You should be more specific about what you are trying to do. :)
I know how to serialize a form:
$("#attributeform").serialize()
but I want to store this in some kind of variable, like a hash, so that I can retrieve these values and resubmit them in order to transition between states.
I think you are looking for serializeArray instead. It produces an array where you can save and edit.
Actually I was able to use a simple hashtable for this. I didn't want to mess with serializeArray because I was actually looking not to hash the form values, but to hash the serialized form to ANOTHER value. Sorry if I wasn't clear.
I am using the post and get methods for Ajax calls, and have a general question. There are two methods I've seen people use on the web:
Construct the URL and parameters by
hand
Use the data parameter
Both approaches work. I've included them below:
// Construct the POST URL by hand
queryStringDelimiter = "?";
settings.queryParam = "q";
$.post(settings.url + queryStringDelimiter + settings.queryParam + "=" + query, {}, callback, settings.contentType);
// Use the data param
$.post(settings.url, {q:query}, callback, settings.contentType);
Are there any situations where you would construct the URL and parameters by hand instead of using the built-in data parameter? Any advantages of one method over the other?
I'd say the data approach is better since it formalizes the process and reduces the chances of producing errors while string building. Besides, the JQuery library will do the string building for you so its basically the same amount of work.
No reason I can think of why one would construct them by hand unless they didn't know of the data parameter if there's more than 1 or 2 parameters, it's also cleaner to keep them separated so if you have to loop through the data object and possibly modify some values you'd just iterate over the object instead of parsing a string manually.
If you let jQuery concatenating the data in to the appropriately formatted string you...
avoid having to duplicate that code...
avoid worrying about escaping the data for transport...
can easily switch between GET and POST requests in the future...
Really, the only argument AGAINST using the data parameter is if you already have the data in a concatenated format.
If I am using a GET I tend to just construct the URL, but when using POST I use the data parameter.
I do it because it is closer to how I was doing ajax calls before jQuery, when I wrote everything myself.