convince me that JSON/XML is better than plaintext for AJAX

[alexweber15]

unless you want to share with others its just extra effort the way i see it.

 

- you have to format the data server-side and then interpret it client-side.

 

2 extra steps (vs plaintext which you just send and output).

 

security?  xml and json are both plain-text with bells and whistles.  there's no extra security there.

 

the only possible reasons i can think of are:

1) flexibility to interact with other sources (web-services and such) - mainly XML because of DTDs

2) organization for large sets of data; being able to pass back objects and arrays for instance

 

for *most* requests, like login forms you return on average 2 values (true or false, and a message) and if you implement half decent security a new hashed-token.  and "true or false" is merely for js to know, not to actually determine whether a user is allowed access!!!

that's what sessions and whatnot are for.

 

so seriously, ive got my flamesuit right here.  let me have it.

im sick of encoding and decoding JSON for ridiculously simple stuff like error messages.

[jwilliam]

I don't think you should be "flamed" for what you said.  In a large number of cases, I think you're right.  For small pieces of html that need to be inserted in the document... just send the html itself.  But there are quite a few situations where sending data back in xml format or JSON (my preference) makes for a much nicer user experience.  Here's one real-life example.  I had an app that had a fairly large form that showed up from time to time.  I decided to just generate the html code for the form on the server side and send it back to the app via ajax.  The end result was a very jumpy transition and much more bandwidth than was needed vs. a fairly simple javascript method to take the necessary data and dynamically create or populate the form via the DOM.

[xtopolis]

Use the right tool for the job.  "right tool" can mean a number of things: cost effective, speed, efficiency, ability to maintain, etc.

 

This isn't a "convince you to use JSON" topic, this is you looking for an excuse to continue or discontinue your current method.

 

My 2cents: Use JSON for things that are primarily Javascript based.  If PHP or Javascript can return what you need... I would use PHP.  Why?  The server hosting PHP is dedicated to handling requests.  They most likely had to access the server anyway, so why not have PHP do the work.  Javascript is cool.. but limited.  It's also based on the client's machine: speed-wise, and also enabled or not.

[alexweber15]

Use the right tool for the job.  "right tool" can mean a number of things: cost effective, speed, efficiency, ability to maintain, etc.

 

This isn't a "convince you to use JSON" topic, this is you looking for an excuse to continue or discontinue your current method.

 

My 2cents: Use JSON for things that are primarily Javascript based.  If PHP or Javascript can return what you need... I would use PHP.  Why?  The server hosting PHP is dedicated to handling requests.  They most likely had to access the server anyway, so why not have PHP do the work.  Javascript is cool.. but limited.  It's also based on the client's machine: speed-wise, and also enabled or not.

 

i disagree its totally about me trying to find a good reason to switch.  when i first started dabbling with ajax about a year and a half ago i didn't know any better so i returned csv strings and then went to pipe-separated strings because commas are too common in error messages 

 

but really PHP makes it easy enough to generate JSON and interpret JSON for that matter with 2 simple functions.  the part i don't like is having to write a specific JSON parser for each scenario or further still having to write a generic JSON parser.

 

after much research on file-based storage (decided to boycott MySQL and learn something new) and whatnot i came up with the following conclusions:

- JSON is better suited for small amounts of data and also more closely represents Objects and Arrays in the both PHP and Javascript syntax.  But eval() should be banned for obvious reasons and I realized that for tiny bits of data like my login form example where I will return a validation a database error/success message or some kind of message coming from the server, if its a one-line message then there's no point in using JSON as its overcomplicating things.

But like jwilliam said if you're passing large(ish) amounts of data or full structures like Objects or Array than JSON makes it more convenient due to its native support for native data types and multidimensional arrays.  (also doesn't have the bureaucracy of XML with its shchemas, DTDs, obsessive well-formedness and silly [CDATA] constructs

But thats both a pro and a con as I see it as its unpredictability makes it harder to write a generic parser.

 

- XML is well... i dunno good for exporting to other services, in which case the aforementioned bureaucracy is a good because if we have a DTD (or WSDL) or something like that parsing it is easy as pie.

 

- And the conclusion I came up with was that for small data-stores using sqlite for example would be a far superior and more robust solution because of the ease of selecting and filtering data without having to traverse the entire set.

 

I know i went on a tangent though, but really, from what was said and from my own conclusions the advantage of JSON over plain-text is merely a practicality and in some cases a performance issue because its just plain-text that's more organized and the enclosing brackets give a false sense of security but eval('{'+jsonObj+'}') shoots that down pretty quickly...

 

keep the feedback coming please!

 

and i vote for AJAX to be renamed to AJAJ (despite not having the same ring to it)