Discussions

News: Bridge the gap between XML and Ajax with JSON

  1. Bridge the gap between XML and Ajax with JSON (7 messages)

    A couple of years ago, many developers bet their futures on XML, XSLT, Extensible HTML (XHTML), and a host of tag-based "X" languages. Now, the new rage is Asynchronous JavaScript and XML (AJAX), and investors' eyes are turning toward data-driven Rich Internet Applications that use JavaScript code. But have developers bridged the gap between XML and this new technology? This article helps answer that question with different approaches for using XSLT V2 to generate JavaScript Object Notation (JSON) from XML data for use in Ajax applications.
  2. A couple of years ago, many developers bet their futures on XML, XSLT, Extensible HTML (XHTML), and a host of tag-based "X" languages. Now, the new rage is Asynchronous JavaScript and XML (AJAX), and investors' eyes are turning toward data-driven Rich Internet Applications that use JavaScript code. But have developers bridged the gap between XML and this new technology? This article helps answer that question with different approaches for using XSLT V2 to generate JavaScript Object Notation (JSON) from XML data for use in Ajax applications.
    JSON is just another hype, just like many other techniques today. Yes, maybe it's almost a standard, etc..., but it's nothing more than a data structure. I don't see there being a bridge between XML and JSON. Theyey are designed for different purposes. JSON is more efficient, but not as rich. In cases where JSAON notations are enough to describe your data model that needs to be communicated, it should be used. An exception would be if your application were inherently an XML application, though it already communicates using XML, has XML facilities, REST interface (and even SOAP). For those applications, it makes more sense to use browser-based transformations from the incoming XML. You can also mix and match, though for small requests that need to consistently poll the server, JSON might be a better solution, if you are suffering form efficiency issues. At the end of the day, you can communicate comma-delimited values. It's about standardization and good design. I look at AJAX based apps as a rich client accessing backend services. Yes, the backend service model can communicate using anything, but most web services today are utilizing XML as a communication medium, though in most cases it's a lot easier to just use that. You can see my blog entry for XSLT/AJAX views... http://www.ilyasterin.com/enteprise_software/2006/09/ajaxxslt_views.html Ilya Sterin
  3. JSON is the only viable tranfer mechanism is you intend to create browser independant 'AJAX' applications as Safari does not provide XPath or XSL support in their browser making it very difficult to do any practical rich client development. If you are only looking to support IE and Mozilla based browsers then XML is a fine choice for data transfer. However, you still face some other issues, and this depends on how rich your applications actually are. XML documents have limitiations (especially within the browser), you can't make references from one document to another (i.e. object references) this means you need one large monolithic document to store all the model data. It also means you need to do things like store id's in sections of the document in order to create references to other sections of the document. Once you have done this you then need very cumbersom XPath statements to refer to to elements that are indexed in this way. JSON maps directly to JS objects, this allows you to do all kinds of useful things like be able to make direct references to sub-graphs with standard JS variables, have many root objects that can still be refered to and can refer to each other. This makes developing applications much easier. Also the evaluation of JSON -> JS Object and visa versa is a very light weight process reducing the cost of communication processing. JSON does have issues, the non-cyclic graph requirement is unfortunate. Mozilla browsers can get past this using a simple referencing mechanism allowing for the serialisation and de-serialisation of cyclic graphs, but IE does not support this behaviour, thus it is not worth pursuing (Since one of the reasons for using JSON is better browser portability).
  4. Agree, the eval and native object graph representation is a + from JSON. It's basically a serialized js object. Whether JS is really an OO language is another question:-) The support of XSL/XPath in non-(IE|Firefox) browsers is not an issue any more with Google's XSLT/XPath library, which is completely cross-browser. It's not as efficient as the native browser XSLT/XPath support, but I believe if use correctly can yield great results. Google apps like Google Maps, etc... use it extensively. Ilya Sterin
  5. Recently we have deloped a project using AJAX and used the above technology for the Presenstion layer.It works quite well. Until the POJO we use the traditional patterns we keep the POJO as flat as possible and use Castor to convert that into XML then using JSON to convert the same in JSObject to be able to use in the view layer.We have no problem with browser (IE & Firefox) to paint the content. Elango Senior Systems Analyst
  6. Has anyone tried Flex/Open Lazlo option? We are trying flex. We did look into Ajax/Json solutions but tried flex due to out of the box features - developer productvity and browser compatibility. We spent a lot of time making app work with IE, firefox (easy part) and Safari (very diff from the rest).Its nice to get over the browser compatibilitty issues for ever since its Flash and some data comes client side reducing network traffic. Overall looking pretty good so far.
  7. A couple of years ago, many developers bet their futures on XML, XSLT, Extensible HTML (XHTML), and a host of tag-based "X" languages...
    Bet their futures? That's a pretty strong statement.
  8. JSON/DOJO/POJO[ Go to top ]

    very nice combo