tags:

views:

45

answers:

5

When we return data from an Ajax call, is it better to return a document containing HTML to display on the page or return XML/JSON data which can be processed?

I know different circumstances may determine what 'better' means, but I really want to know which will be more appropriate for different circumstances.

I am working on the framework for a large ASP .Net application, using jQuery Ajax (forms plugin). My initial thought was to return the data as XML, then process accordingly. Then this increases processing required in Javascript, to populate the page. I am trying to balance flexible, clear and simple.

Thanks in advance for your knowledge and information.

+2  A: 

Sometimes you will need to return only one value, other times (for example trees) you might need to return array of values with different levels.

In general, I would go with JSON.

medopal
Why Json in particular?
Russell
because ajax is done with javascript, and json is easy to write and is a javascript object
Carson Myers
That makes sense, so that means you guys agree that returning the data (in JSON or whichever format) and have an ajax "processing" layer as well?
Russell
I vote for JSON too, it's easy to process and generate in many languages, fast to parse, easily human readable (for debugging) and flexible (no need to define schemas, namespaces and other boilerplate like with XML)
wump
Like XML, you can return anything in JSON, yet better as Carson mentioned, it's a JS object, so you wont need lot of work to parse it.
medopal
@wump, yup I forgot to mention Debugging, hint Firebug :)
medopal
Certainly jquery and associated plugins (eg jquery.forms) have a heavy use of JSON for options etc. This may simplify any javascript processing, with some helper methods, eg. PopulateForm(form, jsonObject); using key/value pairs.
Russell
@medopal - I use firebug daily - how does JSON help with debugging?
Russell
@Russell, when the response is in JSON, Firebug can show a formatted version of it. That's useful when you want to make sure the data is returning correctly or not before you suspect your processing JS code. Something like this: http://shout.setfive.com/wp-content/uploads/2008/12/json-viewer.png
medopal
Thanks for your informative comments. I am still redefining my thinking of the way javascript fits into a web development framework. It really is its own layer sitting behind the HTML (in a good way)!
Russell
+1  A: 

As much as "trying to please everyone is the fast-track to mediocrity" would it not be an option to have the server-side handler for the AJAX call produce XML, JSON or HTML dependent on the value of a variable, called, for instance "format"?

This would then allow you to change the format based on the amount of data being transmitted, the intended processing (on the client-side), and provide for extensibility in the future.

For instance, for a very simple request, you may even be happy just getting a text result of "true" or "false", so you add "format=simple" to the end of the query. When requesting a list of items, JSON may be the better option, so on goes "format=json".

I am suggesting this as it seems to be one of the tricks Google offers with some of their APIs.

Lucanos
@Lucanos, I like your idea of flexibility like that. e.g. for a simple lookup Ajax, where a single object is returned, XML may be better. On the other hand, the system is large and consistency is really important too.
Russell
+1  A: 

Depends on the situation.

1) If you want to simply fill a div tag with server-side HTML (for example for a news site of CMS), transfer HTML and put it in element.innerHTML. This is simple and effective.

2) If you have more requirements on processing the data (a dynamic client side interface, such as a grid, table, form etc) go with JSON or XML.

wump
My expected scenarios will be point 2. Lots of grids/lookups/dynamic menus. Do you think we should increase the amount of javascript by processing the data from the response into the page?
Russell
Yes, if you want any interactivity; it allows for much better user response than doing a roundtrip via the server generating new HTML every time.
wump
Good point, I was just thinking too that by generating HTML in a lower layer adds dependencies to lower layers of cod.e
Russell
+1  A: 

if your AJAX call is to grab some data, have the server return JSON to it. If it's just to get a flag, just have it return 1 or 0 or something. If you want to insert something into the page that can be more easily created on the server, have the call return some HTML.

Carson Myers
So you are saying that it may be better to have a few ajax response data types? (eg simple:objectValue, complex:JSON)
Russell
JSON is simple too: true, false, 0, 1 are valid JSON return values. But if you need it you can return trees [[1],[2],[3,4]]] or associative arrays {key1:"b",key2:"c"} or a combination...
wump
A: 

I think it depends on how narrow is the scope of update that you are trying to make. Obviously, if the area of the page affected by the information that you get from server is something small, couple of controls that need to be updated, it's better to be brief (e.g. JSON) and do the processing client-side.

However, if the result of the server-side logic is updating huge part of the page it might be convenient to simply re-render this part server side and set it as an innerHTML of some container.

Thomas Wanner