Article:		Very Dynamic Web Interfaces
Subject:		I realize that I'm on XML.com, but....
Date:		2005-03-23 07:09:49
From:		mdchaney
Please don't use XML for such a simple request. Actually, I'm not convinced that XML is the best method for sending any data to JavaScript. I do a lot of work with XMLHTTPRequest, and I simply use the standard JavaScript object literal and array literal notations. Now, I know the above is a simple demonstration, but for a simple flag response you need to return only a 1 or 0. To keep with the example, though, you can return a JS object: { method: 'checkName', result: 1 }; Then, the function is simplified: function processReqChange() { // only if req shows "complete" if (req.readyState == 4) { // only if "OK" if (req.status == 200) { // ...processing statements go here... --> eval('response = '+req.responseText); eval(response.method + '(' + response.result + ');'); } else { alert("There was a problem retrieving the XML data:\n" + req.statusText); } } } Obviously, for such a simple example there's little gain. But imagine trying to traverse an entire DOM tree for a large document. Using literals, you can create native JS objects and use the much simpler constructs such as "for/in" to manipulate the data. You can also directly address known data, as shown above. Make the choice between this: response.method or this: response.getElementsByTagName('method')[0].firstChild.data; It also probably goes without saying, but the backend code is also greatly simplified by not having to create an XML document.

Previous Message

Next Message

• I realize that I'm on XML.com, but....
  2005-04-05 17:31:50 emdee1 [Reply]
  
  > Please don't use XML for such a simple request. Actually, I'm not convinced that XML is the best method for sending any data to JavaScript. I do a lot of work with XMLHTTPRequest, and I simply use the standard JavaScript object literal and array literal notations.

  
  That's great... until you want to reuse the logic for something that isn't JavaScript on the otherside. This is exactly the type of thing that XML is for.
  
  

  • I realize that I'm on XML.com, but....
    2005-04-06 23:06:21 mdchaney [Reply]
    
    That's great... until you want to reuse the logic for something that isn't JavaScript on the otherside. This is exactly the type of thing that XML is for.

    
    It's easier to parse the JavaScript object literal notation than it is to parse XML. Also, there are various libraries already available to do so, check www.json.org for more details.

    
    Given the simplification of using a simple object over using DOM methods to get at your data (again: "response.method" vs. "response.getElementsByTagName('method')[0].firstChild.data") it just seems unlikely that bloating your code and making it unreadable on the JavaScript side in the off chance you'll want to reuse this data elsewhere is the way to go. Particularly given that using DOM methods in any language is likely to be as painful.
    
    

    • I realize that I'm on XML.com, but....
      2005-04-26 15:58:43 krufty [Reply]
      
      incidentally, a programmer mistake by parsing literals on a data feed could result in something like

      
      If your datafeed contained:

      
      alert("oops, thought i took this debug line out of here");

      
      you'd execute it. The datafeed cannot accidentally cause the calling page to execute javascript code unless you eval the data coming back.
      
      

    • I realize that I'm on XML.com, but....
      2005-04-26 15:54:22 krufty [Reply]
      
      I think the point is that if you have relatively complex data being returned, and relatively complex data being parsed, its easier to absorb the cost on the hardware side than the development side.

      
      Sticking to XML when you can afford to makes it easier to validate common logic between different languages (think C, C++) .. if you have diff data formats, and diff parsers, and diff developers working on them, you're bound to have more problems than if you data feed is built from a consistant, human readable format. Sure, XML is expensive, but thats the whole concept of data abstraction.
      
      

• I realize that I'm on XML.com, but....
  2005-03-29 22:32:16 w_laks [Reply]
  
  I got a question. How exactly do you return JS Objects in the response? What should be the document type. My server side php code is simply this:
  <?php
  echo "{ name: 'Lakshmi' }";
  ?>
  This works but Mozilla keeps spinning forever I guess because it still expects more content or something. IE does not spin and on Opera this does not work at all presumably for lack of a HttpRequest object.
  
  
  
  • I realize that I'm on XML.com, but....
    2005-04-01 07:04:20 mdchaney [Reply]
    
    How exactly do you return JS Objects in the response? What should be the document type?

    
    Your code looks fine. Just use "text/plain" for the document type. When I do this locally, I simply use ".txt" files.

    
    I just finished a simple application for a client which has a 2.5M data file, the entirety of which is a humongous JS object literal. Loading it locally, including file reading, parsing, and object creation, takes about 2-3 seconds on my computer here (1.8GHz with plenty of RAM). The application is incredibly fast, particularly for dealing with a lot of data.

    
    Using XML DOM in such an application would bloat the data file by at least 25-30% (just looking at adding end tags), and bloat the code by an obnoxious amount by having to deal with DOM instead of simple object properties.
    
    

• I realize that I'm on XML.com, but....
  2005-03-29 22:17:47 w_laks [Reply]
  
  I tried your approach returning a JS Object within curly braces and it works. I am no fan of long-winded Java-style get/set methods either ...