JQuery vs XSLT as REST client for XML resource in the browser

This work is to try and help through thinking about XML results through REST in a browser. If we are going to view the results (in a browser) what are the options that treat the results as a GET resource?
Here are the sample files.
Conclusions:

Parsing XML files is a no brainer to display in HTML

I’d probably avoid using the browser’s xslt engine though – so xslt through javascript is simplified

JQuery is central to the real presentation functionality

I’d start with option 2 personally and then add XPath as needed to target information and then if this display got more complex add in XSLT

You can get there either through (1) XSLT, (2) JQuery itself or (3) JQuery + XSLT + XPath – you really should be familiar with them all anyway

Here’s a couple of main options:

1. XML + XSLT/XPath -> HTML + JQuery => Display
2. HTML + JQuery ++XML => Display
3. HTML + JQuery +XSLT ++XML => Display
4. Flex (+ HTML) ++XML => Display

I have looked at the first two. And that is what I will try and explain. I suspect the other two options are also good. I do have a concern that in using the XSLT parser within a JS plugin it is perhaps delegating too much work to JS (maintenance of enough functionality will probably become an issue). Also beyond that I was looking at is the hyperlinking of resources (my hunch is that JS or Flex will be the way to load and traverse hyperlinked resources) I think that the major concern:

• is a separation of concerns
• keeping a resource as data that can be asked for and can ask for a service to act on it

Separation of concerns:

1. The XML needs to have a life of its own as a resource
2. The client needs to be able to act on the resource
3. The client needs to be in control of all of this and don’t want logic to be hiding at the server
4. On the client, I want to keep separate layout from content from skin
5. For development, I wouldn’t mind some intellisense; I want good debugging help

Some findings:

• One thing to note is that for both approaches I bind a data source to a control. Here I read in XML and load it into an object and then bind this object to the control which then appends the table to the DOM object. This control can also be bound to an html table. In this case, you put a table into the DOM and then the control transforms the table. The later seemed to me to be a server-side solution rather than a late-binding to a resource.
• I also did a sample XSLT of creating table in HTML from the results (results-as-html-table.xsl). The code was too long for me! I have include that file in the source for reference.
  

  Option One: XML + XSLT

  
  This was my initial reaction as the way forward for this solution. Personally, I like XSLT and its declarative nature. But, in practice, I still find it a little slow to programme (I really do forget the syntax and have to relearn it each time – particularly if you start to heavily use namespaces).

• The xslt on a browser has to have a reference to an xsl in the XML - this really isn’t that good as there is only one view per xml (although if you were working outside of the browser this need not be a problem)
• XML in many ways does act on itself because it puts an XSLT across it (although limited to one)
• It was harder to debug the JS in the xslt mode and generally took longer to working in XSLT
• The key thing to remember is that the target platform is HTML/JS and XSLT is good for transformations from one structure to another. The problem is that while XHTML is XML we are really in a programming mode rather than a transformation mode. I think that the part that is best for the tranformation via XPath is taking the results and combining the bits of information together (that is this case would be in a cell).
• I had add extra code to late-bind the data into the control as it wasn’t designed to be used in this way (you could rewrite the component to reduce code though)

In summary, as the transformations got larger, this might still work well. You will need to write a number of xsl files to allow for good modularisation (see DocBook if you have any doubt on this one). In doing, so you can keep alot of the javascript/JQuery work invisible to the main transformations. But I find that really if isn’t great for debugging so I write the JS in another context and then import it back in to the XSL file.

Option Two: HTML + JQuery ++XML

Having looked at the XSLT work, I was in the land of JQuery and was finding it hard to get good, flowing code from the HTML/JS perspective. So while what I want to see needs to be parsed declaratively, the way to display and have interactions with it needs to be procedural code. Note: I had to patch the flexigrid component to allow transforming data from an XML to JSON source. It assumes that the resource gotten is the object presented.

• The HTML/JS using an html container was quicker and cleaner to write. I was easier to use code samples to then customise and extend.
• The browser’s debugging tools such as Firebug played a little more nicely in terms of error handling
• Honestly, this approach took not more than a third of the time
• JQuery gives me iterators and finders that makes my code not look dissimilar to the declarative XSLT (I would also be able to use XPath if I really wanted)
• To keep it clean I will tend to use expected modularisation in Javascript (objects/functions)
• I’m not convinced that the end result is necessarily any cleaner though
• I will be able to put unit tests around it though
• the HTML file is itself a resource
  

  Simiarilities

• I only need to load the xml once
• both use the same libraries
• both need to be improved to do a DTD (xsd) check?
• the REST approach requires that the client transforms the XML to a format that can be bound to the control
  

  Where to?

• I probably stick with the HTML approach
• I’d keep extending the JQuery plugin approach which allows for nice configuration of views
• I can use either the each iterators with find in JS or use XPath to work out what data I want to (re)present
• I would probably add another layer of abstraction between the model object and the data source – at the moment what required from the data source and format of the binding object are combined. A factory would easily create that separation – but was too much for this example
• Alternatively, I would extend the column model so that you can use XPath configuration of data rather than need the pre processing callback in the first instance
• go and look at options 3 and 4 above at some stage (3 is likely to end up as the alternative above)
  

  Appendix A: Reference Formats of JSON data format for server

  
  { page: 1, total: 239, rows: [ {id:'ZW',cell:['ZW','ZIMBABWE','Zimbabwe','ZWE','716']}, }

Share on Facebook Share on Twitter Share on Google Plus

About Fikri

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.