The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

AJAX without XML

I wrote a small piece about AJAX without XML.

 http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=AJAXWithoutXML

Is anybody else doing it? Please share your thoughts...
Pavel Simakov Send private email
Monday, November 21, 2005
 
 
It just seems like you'd have to be SOOO careful doing this.  Anytime you use an eval in your code, it takes careful precision to not allow your users to sneak anything into their input that can be evaluated maliciously.

I know.  We should always be this careful.  But look at myspace.com for example.  A huge network that some dedicated hacker was able to break with a creative JS worm.

Lastly, you mention how it is expensive to parse XML, but it's usually happening on the client side, so I don't see it as an issue where someone would be overly bogged down by some XML.

Just my thoughts, I'm sure it can be done safely, but it seems like a lot of extra coding that can be skipped by using XML.
Ben Mc Send private email
Monday, November 21, 2005
 
 
Don't use a drop of XML. Seems uncecessarily complex to me. Imho, the browser is a semi-independent device under the control of the server. There's no need to pretend it's completely separate.
son of parnas
Monday, November 21, 2005
 
 
Depends what you need to do, but passing around strings and ID's works out pretty well as long as you don't plan to build  an API around it.
Sassy Send private email
Monday, November 21, 2005
 
 
This style of passing chunks of Javascript around is currently buzzworded as JSON: JavaScript Object Notation. There's even a spec at http://www.json.org including a parser so that you can get javascript objects out of json messages without having to call eval.
Chris Tavares Send private email
Monday, November 21, 2005
 
 
Isn't this essentially using telnet again?  You'd better build out a completely secure telnet server on the server side, otherwise people will abuse the 'new API'.  Am I right?

If you hate the XML part of this, why not write one wrapper function to extract/push your standard data from/into an XML chunk, then you can pretend you're not using XML?  Am I right (again)?
pds Send private email
Monday, November 21, 2005
 
 
You forgot JSON: http://www.json.org
Berislav Lopac Send private email
Monday, November 21, 2005
 
 
Yeah, I've done this too.  It was slightly different, as we were doing it with iframes at the time (which means that we didn't have to eval - that was automatic).  Depending on what you're doing, it can be a lot more convenient to have the data in js objects rather than XML.
The reason for sticking with XML is that it's a lingua franca.  If you want another app to access the same data, all of the sudden, you need a javascript interpreter.  Whereas if your server queries returned XML, all you need is an XML parser.  So there are more opportunities for growth if you stick with something more open.  This may not matter to you, but it's something to keep in mind.
But how hard is it to write a little javascript factory function to go from an XML DOM to an object array?  Seems like you could do it in a dozen lines.
a unique name lets you know it's me Send private email
Monday, November 21, 2005
 
 
And to respond to the concerns about eval'ing user-supplied data: It's just a matter of encoding the data before sending it back, like any other XSS-prevention.  You're just using javascript for the transport mechanism - it's not magically more dangerous than "Response.Write strSomeString".
I will say that a downside is if you mess up the javascript (like you forget to escape a close-quote), the user experience is often worse than with XML transport.
a unique name lets you know it's me Send private email
Monday, November 21, 2005
 
 
The whole point of bringing up the eval problem is due to "if you mess up".
Ben Mc Send private email
Tuesday, November 22, 2005
 
 
What I meant is that if you eval and there's, say, a syntax error in the javascript, then you can't recover and the user is probably going to see it.  Compared to XML, where it's much easier to detect and handle a syntax error.  That kind of "messing up" is distinct from the security concern you originally raised.  As I said before, there's no *additional* security concern that isn't always there in a web app.
a unique name lets you know it's me Send private email
Tuesday, November 22, 2005
 
 
I do not think anyone wants to generate JSON, XML or JavaScript objects by hand. This is typically done with a generator of sorts that takes object instances and creates JSON, XML, or whatever representations. So chances to "mess up" are low. If one starts injecting more elaborate things into JavaScript - the mess is quite easy to get.
Pavel Simakov Send private email
Tuesday, November 22, 2005
 
 
Using JavaScript as the data transport encoding is very popular and can be extremely handy if your application is closed (ie you are not going to provide the data to someone else). Furthermore, if the data you are returning a single JavaScript object that needs to be used _in JavaScript_ then by all means use JSON - it is much nicer than parsing the XML DOM to look at values etc.

But if you are returning an array of data that needs to get into the web page DOM (and will maybe need sorting / filtering on the client) then use XML since XSL can be much easier to use for some people and it can be re-used on both the client and server.

If speed is important you should also take into accound the browser demographics when considering using JSON [1]. XML + XSL is far faster than JSON in IE and vice-versa in Mozilla browsers.

[1] http://blogs.ebusiness-apps.com/dave/?p=45
dave Send private email
Wednesday, November 23, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz