Good day.
I'm new to jQuery, and have a passing familiarity with javascript, having spent most of my time on the server side.
My interest is in posting in the browser a multipart/form-data form object consisting of one text field and one file. In response, the server returns a multipart/mixed response consisting of one part html or json, and one part application/octet-stream.
My goal is to learn how to extract with jQuery the html or json part and optionally display it in a target div (if html) or redirect to a URL in the json (if json), and save the octet-stream to disk. Preferably in that order.
Would someone be kind enough to comment on whether such multipart/mixed response parsing is possible with jQuery and some idea of how to do this.
Actually, while I much prefer jQuery, I'll learn something from answers framed in any popular javascript framework, and even unadorned javascript itself.
Thank you.
GREAT question. Judging by the existence of this plugin im assuming no:
I also found this link in a discussion of that plugin, which might be helpful to you:
http://about.digg.com/blog/duistream-and-mxhr
Have a look at the jQuery's API. If your AJAX call returns HTML you can use the .load function. If it returns JSON you can use the .getJSON function.
Related
I've read a lot about sanitizing and escaping of untrusted data, e.g. starting with this cheat sheet. But I didnt get the full picture yet. I am struggeling to understand, what principles I have to follow in order to parse JSON data safely.
Let's be more precise by means of an example. I retreive an Object in JSON format via an Ajax call from my server. The object shoudnt contain any malicious code, but.... you never now. So I parse the JSON data using JSON.parse in JS. The sesult is a multilevel JS object. I use the object in various way, e.g. creating table code via JS and writing it in the DOM.
Is this approach safe. Or do I have to somehow escape the invidual items of the object individually? Appreciate your help. Happy to concrete my example if necessary.
I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page ( I'm basically trying to display invoices on a web browser)
My skill set is HTML/CSS and I understand a little JavaScript
I've managed to pull XML data into HTML using http request and style that information using xslt
Really what I'm asking is what is the best solution to my needs is it using the above method then using xquiry to add up values or would I need to learn a bit of Ajax, Json and calculate the values with JavaScript?
You really should learn AJAX in order to fetch and manipulate data instead of fetching presentation parts. That's the way everyone follows as it allows more responsive interactions with the user and a cleaner architecture in case of complex interactions.
But that doesn't mean you must abandon XML : originally AJAX was built on XML (the X in AJAX) and not JSON.
Personally I prefer JSON, and I think it will be easier to manage in the long term, but if the server side is hard to change, you can fetch the XML (look for example at jquery's ajax function), build javascript objects using it, and then change your screen using those data. If later you decide to use JSON instead of XML, you'll just have to change the "parsing" part of the client code.
"I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page"
You can do this with either XSLT or javascript. However, with XSLT things can become pretty complicated, depending on what version you're using. XSLT 1.0 has pretty limited set of functions for aggregating results. For all XSLT, you can't reassign variables you'll have to solve many of these things with recursion. In my opinion, not really a comfortable method.
Regardless of the choice between XSLT and Javascript, I would also question the architecture that would put this kind of logic in the presentation layer in the browser. I think it would be better if the server side would perform all the calculations that are required, and limit the browser's tasks to styling the output.
New to JSON, just trying to get my feet wet.
I know how to do this with XML via javascript, but am trying to learn how to handle JSON objects so I can switch over.
Basically I want to search through all "permalink" tags in the following JSON object and, when I find the right one, save its corresponding "title" and "id" tags to javascript variables:
http://api.soundcloud.com/users/goldenstatewarriors/tracks.json?client_id=02db8e29aa2fb5bf590f478b73137c67
Can this be done with only javascript (no PHP)? The main issue I'm facing is simply grabbing the text from the page and converting it to a json object.
You need to use a JSON parser in order to transform the JSON string into an object you can handle natively in JavaScript. Recent browsers have this functionality built in as JSON.parse(), but obviously this will not work in older browsers (we're talking very old browsers here).
A solution to that problem is to use the JSON parsing library available here. If native browser support is detected, it simply uses that, otherwise it has a JavaScript implementation to achieve the same result. The file you'll need is json2.js - simply include that as you would any other library and away you go!
An example of the code would be:
var dataObject = JSON.parse(jsonData);
As a side note, XMLHttpRequest is somewhat of a misnomer these days. It is simply a mechanism for making HTTP requests and retrieving the data returned, it doesn't have to be XML. It can be plain text, (non X)HTML, JSON, anything. In fact, I don't think I've seen anything in the wild return actual XML data for an XMLHttpRequest in a very long time.
I can do it via jQuery and/or Underscore JS as arrays of data, but I want to learn the API for just pure RAW JSON. For example, I know there is:
delete json.item
Which just simply deletes the item, but is there a set place I can go learn the full API?
--UPDATE--
I guess this came out wrong. I want to learn about Douglas Crockfords library, all of it. The JSON.func() library, not just "JSON" which is a string. For example he has a function called stringify etc. His site is a total mess, so I was wondering if there was a better place to learn about that JSON library (which has become the standard.)
There is no such thing. Raw JSON is a string, and attempting to manipulate it will only serve to damage it. Always manipulate it after decoding it.
delete will modify the property of an object, it won't let you manipulate JSON (unless that JSON is stored as the property of an object, in which case it will delete it entirely).
You appear to be asking about how to modify a JavaScript object, in which case, the "API" can be found at https://developer.mozilla.org/en/JavaScript/Reference
I have some jquery/php interaction set up on a page. It submits some data to the server and gets back records of data which are then to be aligned on the page for comparison and possible action beyond that.
My question is what is the best practice for returning the info and then displaying it?
Return JSON object and then create
html on the fly with js and display
the data?
Return JSON object and then
put that data in already created
containers for the data on the page?
Return pure html from the server and
just put that on the page?
I was rolling these through my head last night and couldn't really figure out if one way would be better for any particular reason.
I'm not a js guru so wasn't really sure the pros/cons and caveats to these different methods.
I think it ends up depending on your app.
Pure HTML is the easiest, you just drop in in place and viola. JQuery makes it a breeze to add the proper events and what not.
However, whenever I've used AJAX it's always evolved into returning JSON and building elements on the fly. If you are populating a tree for example, it may become messy to get the proper nesting. This forces you to have to do client side code anyway at which point simply using JSON from the start is cleaner.
Also, If you plan to use the data calls from other pages then using JSON is the way to go because the HTML will bee fixed.
This completely depends on the way you have things set up in your application. I, for one, prefer to return JSON (second approach in your list), because I have an 'error code' parameter that I check in onSuccess function before updating the content on the page, and if it's not zero then I notify the user of the error, including the error message that came back from the server (server-side validation, database timeout, etc.).
I think you're missing a perfectly valid option, one which I use often. This is my typical schema and it has yet to fail me... :-)
Here's the basic jQuery template I use:
$(function() {
$.getJSON('/some/page',{foo:bar,bar:foo},function(json) {
if(json.outcome == 'success') {
$('body').prepend(json.html);
} else {
// Somehow let the user know why it didn't work
alert(json.error);
}
});
});
Here's the basic backend (PHP in my case) structure I use:
<?php // Page: '/some/page'
/* Blah Blah Blah... do whatever needs to be done... */
// If everything turns out okay (assuming '$output' is the HTML
// you want to display...
echo json_encode(array('outcome'=>'success','html'=>$output));
// If something goes wrong... just do:
echo json_encode(array('outcome'=>'error','error'=>'Uh oh... something is broken'));
Naturally, you'll want to be more specific with your error by putting them into some variable or something. But, you should get the idea. Also, of course you can add more information to the json output. You can have some pre-made HTML and also some other information like a 'success notice' or a new class name for some element, I dunno... whatever... the possibilities are endless.
Anyways, the reason I choose this route is because it's usually faster (based on my experience) to append pre-made HTML to the DOM rather than looping over JSON and inserting the stuff unless it's just, like, a bit of text to replace into an element. But, the method I've shown is, IMO, the best of both worlds. You can attach HTML as a string to one of the JSON properties.
Happy jQuerying :-)
The "possible action beyond that" part of your question makes a big difference. If you need to do other things with the data besides display it, returning as JSON is a clearly better option because you can work with the data as a native JavaScript object instead of having to traverse the HTML DOM. If all you ever intend to do is display it, I don't see any reason to go through the trouble of building that display in JavaScript; just build the HTML in your presentation layer on the server.
This came up recently and possible a dupe: The AJAX response: Data (JSON, XML) or HTML snippet?.
If you are going to be creating HTML then you may as well be returning HTML directly and inject it into the DOM. However, there are times you need to work with objects which is where JSON comes in handy.
If you return a Person object for example then you can greet Person.Name and show Person.Preferences which is really handy. It depends on your design but the general considerations should be to keep HTML out of Javascript unless you're building RIA.
I have used all three and have come to the conclusion that returning HTML is better when introducing new elements to a page.
My experiance is that when building HTML with javascript I am usually replicating work that will have already have been done for the non javascript user journey.
I still prefer parsing json for updating existing elements or creating javascript only functionality. I tell myself this for bandwidth, but I think it just because I love javascript.
As a forth option, I read a great post about how Flickr deal with vast quantities of data with string concatination. Basically just parse a big o' string down the pipe and chop it up on the client. This significantly reduces the on the server, with only a marginal increase on the client.
Returning pure HTML is the best solution. For the most part gzip should neutralize any difference in bandwidth, and rendering via javascript on the client can be slow if the client is a crappy machine. Finally, writing javascript to render HTML is hard to work with compared to using something nice like a view if you use MVC.