[e_i_pi]

In my current framework, when the user makes a request to the server, in some cases, multiple AJAX requests are fired. For instance, the request may need to:

• Send data to be stored in the DB (no response)
  
• Refresh an information panel on the screen (e.g. HTML response)
  
• Refresh a different area of the screen (e.g. HTML response)

Currently, I am handling this by firing off 3 AJAX requests. This is not ideal, as there is a limit to the number of consecutive requests a browser can have open, and it also starts up three sessions on server-side. I would prefer the AJAX request to send over a package of data using get/post and have the server-side receive the package, parse it out, and form up it's own package to send back. This package would be an object containing multiple packets of HTML and one packet of Javascript. Delivery would be kind of like a warehouse receiving an order for multiple items - the shipment won't be made until all the requested items are bundled together, ready to be shipped off.

All this server-side stuff is fine, I have most of it in place with the current setup, but I'm wondering what the best option would be to send the data back to the client? As far as I can see, there are two options available - JSON and XML. Is anyone aware if there is preferred data format, and whether there are issues with either one that needs to be considered? Does encoding come into it at all? What happens if one of the HTML packets contains a special JSON/XML character/phrase, such as } or </end_of_my_xml_element>.

Also, once the package is received by the client, the scripts will need to be evaluated. I'm guessing the eval() function is the way to go, but have never used the function myself, and am aware there is a field of thought that eval is "bad". Can anyone shed light on whether this is a good/necessary use of the eval function? To me, it looks like it is.

[Dormilich]

encoding: JS uses Unicode by default, so you should serve that encoding. if the XML/JSON is valid on the server side it also is on the client. both are data exchange formats, after all.

eval(): what for? XML responses are automatically parsed by the JS engine, for JSON there is JSON.parse() (unless you have a very old browser who does not support it natively, but there are libraries for that).

speed: JSON is usually considered faster. exceptions may be if you need to transmit objects of a certain class (cf. WDDX) (which cannot be done using pure JSON) or if you pass ready to insert HTML snippets (e.g. elem.appendChild(xhr.responseXML)).

[BetaWar]

With AJAX, I normally return JSON. I like the format better, it is cleaner (to me) and it parses directly in to Javascript nicely (since it is javascript in the first place).

The nice thing also about JSON is that the server-side and client side functions for parsing/ stringifying the data should work with the same format and escape things (such as HTML, or }, or "s) for you meaning that you don't have to worry about it. I don't believe that XML stuff in PHP automatically adds the <!CDATA (or whatever) to the tags so the HTML content would be a special case if using XML (and require more work as a result -- though not much).

It basically comes down to preference. I prefer using JSON, so I do.

One thing to keep in mind:
XML is verbose:

<my_extremely_long_tag_name_here>
some data
</my_extremely_long_tag_name_here>

Where JSON is slimmer:

"my_extremely_long_tag_name_here": "some data"

So, if you are absolutely trying to get the most speed possible out of your AJAX, JSON will be smaller and generally faster as a result. Though on a 5+ Mb/s connection it likely won't matter overall (no noticeable difference to the client). This may also play into a decision if you are worried about bandwidth (again, not normally an issue).

Hopefully that puts things in to perspective.

Now, if I was going to send/ receive a response for multiple requests at a time, I would do something like so:

[
  {
    "req_type": "data_entry",
    "relevant_data": "..." // whatever that is, even other elements as needed
  },
  {
    "req_type": "refresh",
    "element": "something"
  },
  {
    "req_type": "refresh",
    "element": "somethingElse"
  }
]

Hope that helps.

[e_i_pi]

Dormilich, on 14 September 2012 - 08:41 AM, said:

eval(): what for? XML responses are automatically parsed by the JS engine, for JSON there is JSON.parse() (unless you have a very old browser who does not support it natively, but there are libraries for that).

I envisage the server response to be similar to the format that BetaWar posted:

[
  {
    "html": "<span>Hello World</span>",
    "target_id": "MyHtmlDomElement"
  },
  {
    "html": "<span>Hello World again</span>",
    "target_id": "MyOtherHtmlDomElement"
  },
  {
    "script": "<script type='text/javascript'>alert('Hello World');</script>"
  }
]

Once the AJAX request receives this response, it has to iterate through the elements, inserting HTML where applicable, and finally evaluating the script (as the script may have dependencies on the new DOM elements). I imagined that the client-side response handler would terminate with a script evaluation. Is there some other way to handle this that I'm not aware of?

BetaWar, on 14 September 2012 - 08:53 AM, said:

With AJAX, I normally return JSON. I like the format better, it is cleaner (to me) and it parses directly in to Javascript nicely (since it is javascript in the first place).

The nice thing also about JSON is that the server-side and client side functions for parsing/ stringifying the data should work with the same format and escape things (such as HTML, or }, or "s) for you meaning that you don't have to worry about it. I don't believe that XML stuff in PHP automatically adds the <!CDATA (or whatever) to the tags so the HTML content would be a special case if using XML (and require more work as a result -- though not much).

It basically comes down to preference. I prefer using JSON, so I do.

Strong arguments, and they make sense. I was leaning towards JSON, I think this has nailed it in.

Quote

One thing to keep in mind:
XML is verbose:
Where JSON is slimmer:

I'm not worried about the extra 1-2kb going over the wire, I could leverage more efficiency out of caching at this stage.

Quote

Now, if I was going to send/ receive a response for multiple requests at a time, I would do something like so:

[
  {
    "req_type": "data_entry",
    "relevant_data": "..." // whatever that is, even other elements as needed
  },
  {
    "req_type": "refresh",
    "element": "something"
  },
  {
    "req_type": "refresh",
    "element": "somethingElse"
  }
]

And that's how I intend to do it. I'm already doing something similar when I'm packaging up the data that get's sent via jQuery $.ajax(). The client-side stuff isn't an issue when it comes to sending the request, it's the response handling that has me thinking.