I'm interested can I store into client side for example large hashmap or a List? I need something like a temporary cache to store user session data.
In theory, you could use HTML5 client side storage in JavaScript. So far now, no JSF components exists which could do the job transparently. You'd need to write all the necessary JS code yourself or grab jQuery.
All JSF as being a HTML code generator can do for you is to print Java objects in JSON format as a JavaScript variable assignment with help of a JSON library such as Google Gson.
<h:outputScript>var data = #{bean.dataAsJSON};</h:outputScript>
The getDataAsJSON() should just return an already converted JSON string.
Related
I am able to send image/file and normal key value which is being served as normal json later. I am using the form-data type of body in postman and a node server.
To handle image i am using multer on my node server.
But what makes issue is when i try to send the nested json and image together.
I am not able to do this thing.
Everything is fine but this is how the nested json is logging in the terminal :-
Please! Any help would be great to get the nested data object also in actual json format but not like this string as shown in terminal photo.
JSON can't contain binary data. What you're asking isn't directly possible.
The ideal thing to do is a multipart request, which is what you're getting in your first example. Note that one of those parts could be JSON, and you can just reference the other part by name, or with some other identifier.
The wrong way to do this is to base64 encode the data and put it in your JSON. If you do this, you'll get what you're asking for at the expense of 33% overhead in file size, wasted CPU and memory on each end for encoding/decoding, and significant waste in memory for your JSON parser which now has to chew through all of this extra data.
An alternative is to use a format that supports binary data, like CBOR. CBOR works in browsers, is streamable, supports all of the types of JSON and then some, is extensible, and standardized.
One solution is to split image upload and record upload into two separate services and call in UI one after the other.
It may be late but I faced the same issue, what I did was,
1: send data through form-data body and had 2 parameters.
file (the file which we want to send on backend using file field)
data (a string in json format using the text field in form-data).
example:
data : {
"words":500,
"model":0,
"video":true,
"user_id":"user1"
}
I sent this in the request. Remember that when we send using form-data we have 2 separate choices file/text. Since this is text so the whole string is considered a text. So, essentially the data parameter is a string. When I receive this request on backend in django I do the following to get the actual json in json format.
attributes = json.loads(request.data['data'])
This converts the data parameter which was first a string, into a json just as we wanted.
Hope it helps others.
This is just a general question but I can provide an example if necessary. I've been working on a MongoDB/Mongoose, Node.JS, Express, and Handlebars stack app recently and I've ran into some issues with what is being passed from my route to the client side when dealing with Mongoose .find() queries.
I prefer to async await my queries. I have a deeply nested populate query that brings in all the data I need into one object. This is a very simplified breakdown of what I do
async function() { const finalObject = await Model.find({}).populate([*alot more populates*]) }
I pass this into my res.render() route, as so:
res.render('index', { finalObject });
The majority of my experience has been pretty straight forward. I have one issue in a separate stack overflow question about populating the same model twice in one chain (at different levels). I won't address that here.
I decided to do some calculations before passing the object to the route and attach some new values to the properties of the documents. This is where things get weird. I do some calculations and add new properties to documents (these properties are not part of the Schema). When the object is passed to the client-side, those properties I added are available to use (no problem here).
I needed to decode the finalObject into JSON and pass it as JSON as well for an easy use of the data in my client side JavaScript encodedFinalObject = encodeURIComponent(JSON.stringify(finalObject));
I decode it on the client side: clientSideFinalObject = JSON.parse(decodeURIComponent(encodedFinalObject)); and the properties I added are not there!
I'm wondering, how could the new properties I added pass through when I send the object but not pass through when I send the JSON? The decoding is the last thing I do before rendering the page, so it's not a matter of not having my code in the wrong order. I add the properties to the object then decode it.
Some research led me to find out that Model.find({}) does not return a native JavaScript object, but instead a Query. I'm assuming this is a user-defined class data-type that has special behaviors. My assumption is that between the passing from the back-end to the front-end, there is some middle step where the Query does its final processing.
The opposite situation has also occurred. As a solution to this, I decoded the Query finalObject immediately after the Model.find({}) and re-encoded it into a native JavaScript object. After that, I did all my calculations, attached the results as properties to the documents, and sent that new version over as the main finalObject (I still also sent over a separate decoded object for client-side JavaScript use).
This solved the issue of the new properties not being there. They appeared, but this time the decoded then re-encoded finalObject did not have the virtual properties of my Models. The main model has a virtual property that calculates some of it's other properties. It's almost as if that part of the query didn't execute within the .find({}) process. So, when I decoded the finalObject, the virtual properties were never there and were never decoded.
Can anyone explain to me what is going on? Thank you!
I have a web app that include blockly and I want to be able to save the structure user created on blockly on backend db.
I just want to know how to get the current workspace structure so I can post it to server to save it.
and then load it again when user login.
Thanks.
From Importing and exporting blocks:
If your application needs to save and store the user's blocks and restore them at a later visit, use this call for export to XML:
var xml = Blockly.Xml.workspaceToDom(workspace);
var xml_text = Blockly.Xml.domToText(xml);
This will produce a minimal (but ugly) string containing the XML for the user's blocks. If one wishes to obtain a more readable (but larger) string, use Blockly.Xml.domToPrettyText instead.
Restoring from an XML string to blocks is just as simple:
var xml = Blockly.Xml.textToDom(xml_text);
Blockly.Xml.domToWorkspace(xml, workspace);
I am working on an application that uses MongoDB for data persistence, alongside the mongoose library to allow angularjs to communicate with it. I'm using Postman to test my routes, and that's where the problem comes in.
In MongoDB, I inserted an entry thusly:
db.posts.insert{{id:6, author:"Blah", area:"Sport", body:"bleh", user_id:6, comments:[{author:"foo", body:"bar"}]})
I then queried it through Postman, and it successfully returned the Post, but there was a problem. The comments array had been returned as a strange data type, object Object, and I could not access it from my HTML files.
This is what Postman retrieved:
{"_id":"5536112cffc7bf00b2585d24","id":6,"author":"Blah","area":"Sport","body":"bleh","user_id":6,"comments":["[object Object]"]}]
I want to be able to access the author and body elements of comments independently, or else to be able to get at them from my http files. Does anyone know how I might stop this Object-ification from happening, or failing that, how I might query the data from this new Object?
Thanks.
Instead of passing complete db object we can pass required parameters. below is the example to form the required parameters.
res.json({"author":item.author,"body":item.body});
Here You can find call back function and array conversion from the cursor
Why we use json and xml for web api rather then othen platform like jquery and array.
Its interview based question and I was enable to response .
JSON and XML are ways to format and data-interchange.
JQuery is a library was built on top of javascript. so it has nothing to do in data-interchange.
Array by its definition: its a method for storing information. in other words you can use arrays in any format you want to store data.
In Conclusion, Web API is a service that provides or gathers data. and in general you can exchange data between client and server by JSON, XML, or you can use whatever data format you want such as HTML. JQuery can be use to call the Web API that can return an array of data in any data format.
This is not compulsory that you have to return the result in JSON or XML, but most of the time we are returning values in these format because there are media type formatter for JSON and XML, the capability of media type formatter is to read the CLR object from HTTP message and to write the CLR object into HTTP message. This is the main reason that we return values in JSON and XML format.