jgchristopher blog

"1) Ajax and XML, A Match Made by Acronym - Ajax and XML actually aren't necessary for Ajax. No, not at all. Ajax actually prefers JSON! What the heck is JSON you ask? It's the JavaScript Object Notation. It's a much better way to transfer and parse data over lightweight HTTP services. Waaaay better than XML/HTTP, REST, or even, god forbid, SOAP. Don't even ask about WS-*. Don't believe me? Then read the docs on the eval() function in JavaScript. Good, huh?. Next test: Try to send lists of data in XML to your Ajax client and not get tired out writing the (inevitably buggy) DOM navigation code. You'll switch to JSON. Your HTTP service developers will thank you. And everyone will be happy. Well, except folks that want interoperability and performance over ease of programming. Those obviously picky folks should just stick with XML, particularly if they've already heard of it."

5 Earth-Shattering Things You Should Know About Ajax And Probably Don't (web2.wsj2.com)

In his blog, Dion Hinchcliffe, brings up a point that I have been fighting, and probably will continue fighting, at work. Currently, a lot of our stuff is being pulled from a DB (tabular format), marshalled into XML (Castor), returned to client via XHR, and then parsed and formated for tabular display, via JS, on the client. This seems like a total waste to me. Not only are we doing an unneccesary transfer to XML, each client is left to format the data (setting decimal places, rounding data, etc...).

My point of view is to grab the data from the DB, have a common library to format the data, it is weather data, and then use a templating system, Velocity in our case since we are dealing with Java, and return Javascript objects to the be eval()'ed on the client. No more needless XML junk in the middle.

As for JSON, I haven't looked at it enough to decide its usefulness. What is different than just passing data into a templating system to build a normal JavaScript object?

Technorati Tags: ajax, javascript