I am using Ajax in my web project. The requirement is to return lots of data from mulitple tables in database, to UI (jsp) page. I have multiple Java classeses with getter and setter methods to hold those data. Is there any way that I can pass these entire Java object itself to JSP page using AJAX. So, that on JSP page I can retrieve the values from using getter method of those objects . Storing those bulk data in xml element of XML response document and retriving back them on JSP and then adjustung for proper display is very painful .
Can someone please suggest somw easiest way to get Java object on UI page using AJAX ?
Hi thanks for response.
But unfortunately I don't have any idea if JSON.
Will it be recomendable to use Castor tool which will marshal and unmarshall the XML document ? Will it reduce my burden of creating XML document for Ajax response and further retrieving from xml elements ?
marlajee Borstone wrote:But unfortunately I don't have any idea if JSON.
I never find a good reason for using XML response instead of JSON response. All people I met said, "Look, its XML, a widely accepted markup language and its seamlessly get integrated if you're dealing with HTML and DOM things.."
But I stick to the JSON, after all its easy to use and straight forward.
To OP: other than JSON, there are two possibilities,
1.) You can look at Rhino Engine (Could be helpful to script java, but i doubt if this is 'exactly' what you are looking for),
2.) Use JAXB on server end and parse the XML to create an object literal out here?
Isn’t the “JSON vs XML” debate a bit like a “PNG vs JPG” debate, in which developers of image-display applications decide their apps will handle one or the other?
In a services-oriented world, once you’re past same-site restrictions (via signed scripts or trusted zones), you will have occasion to consume services providing SOAP, POX and JSON data, based on the service-providers preference regardless of your’s. Sure, if you control the service side, JSON can be much more efficient; but existing Web services won’t add this to their APIs just to make your life easier.
IMHO, the smart path is implementing a framework that can handle various data formats, via various retrieval methods (SOAP, REST, HTTP-POST, etc.) — possibly marshalling everything to JSON for faster processing.
I like JSON, but there are organizations that already have a lot of things going on for them with XML, you can't just argue with those people because its either:
2.) More "bandwidth-friendly" <-- I don't even know if this is true, I'd like to see performance benchmarks on JSON vs XML with same datasets.
3.) Makes life easier.
I know that there a lot people who have had issues with parsing and processing XML being pain in the butt, but there are frameworks out there that make your life easier if thats a concern;
Trilochan, while most of what you said is probably true in general cases, in this case I can't agree. For dealing with AJAX, assuming you have control of the server side (which the OP does), there should be no doubt what data type is returned. It should be JSON or HTML (for those cases when you just need to update a div with some content). Yes, when dealing with web services in general handling different data types is a great notion. With regards to JSON being more bandwidth friendly, you don't need benchmarks for this. You simply need to use common sense. JSON can represent the same data as XML using fewer characters. Fewer characters means less bandwidth.