XSLT is a giant pain

Some of you may be aware that XML+XSLT 1.0 can be rendered directly by modern browsers (even IE6!), which led me to thinking that it may be a good idea to give it a try and see how good or bad it was.

The process: for a given page (say, a search page), pull the data out of the database that you need in the controller and then output all the raw data as XML needed to generate the page in the template.  For a search page this would be the search results, the user's name (if signed in), etc.  Then you have your XSLT stylesheets.  Since this is all client-side, each one you have generates a request.  If you have one stylesheet that renders the initial page, and that stylesheet requires 4 other stylesheets...well, you have 5 requests right there just to display the page.

These other stylesheets should be mostly static, I'd hope.  In my mockup I didn't have to make any of them dynamic, but then I wasn't trying to do anything super advanced.  Anyway, Thin is smart enough to send 304s for the unmodified XSLTs, so at least that's good...

Other notes: one can do server-side rendering, but that's not the point of this exercise -- I want to do pure non-Javascript client-side rendering.  Unfortunately this also rules out XSLT 2.0, which was only finalized in January 2007 and would probably ease some of the pain.

Anyway, time for Code!

Code

Adding HTML elements based on data

...is a pain.  See here for my solution of preserving dropdown selections after a search (i.e. you search in a particular category and that category shows up in the dropdown on the end page).  Grotesquely verbose?  Why, yes it is!  I don't think there's a better way, either -- it would be acceptable to have a function that outputted XHTML instead of a template, but I think that's that's a 2.0-feature only.

Changing values based on data

This one isn't quite so bad, actually.  As with the previous example, though, you'll notice that you can't pull data in from the query parameters -- it has to be pulled in from the XML.  The original request has access to the query parameters, immediate requests could have access to the query parameters (since the original request url is passed in to immediate requests as the referrer), but non-immediate requests couldn't have any access to the query parameters at all whatsoever.

So what does this mean?  All data needs to be in the XML.  Not just product search results and personalization data, but also what the search query was, what the category was, what the sort order was, etc. if you plan on displaying any of that information.  Ugh!

Preserving query parameters in links

Guess what, more fun!  Check this out.  This is for pagination of search results -- all parameters needs to be preserved except for the page, which obviously changes.  Since this time the data needs to be stored in the attribute of another tag, we have to capture the template call into a variable first.  Cool, huh?

If anyone knows of a better way to do any of this with XSLT 1.0, please do let me know.  I am quite the novice and am just posting my discoveries thus far.  No guarantees of completeness.

Other issues

Javascript/jQuery

I was trying to figure out how to pull data from the original XML sheet via JavaScript, but it seems that JavaScript only has access to the rendered XHTML.  I could do an AJAX call to re-fetch the XML sheet and operate on that, but that seems silly to me.  I've tried looking for a cross-browser non-plugin solution but I don't think jQuery offers anything in this way.

Discussion

In regular HTML, you have HTML, CSS, and JS -- typically referred to as Structure, Display, and Behavior.  But really, HTML is typically structure and data combined, plus elements of display.  XML+XSLT is nice in theory because it explicitly breaks up structure/display and data.  But how much does that really buy you?  On modern MVC-style web frameworks, the controller passes data to the view/template so that the data can be rendered.  But with XML-XSLT the controller renders XML so that the client can transform that XML using the XSLTs you provide.  What's the point of emitting XML when you could just emit XHTML?  Frankly, data and structure don't *need* to be separated -- if you want just the data, then you need to set up a web service.  Frameworks like Ruby on Rails make this trivial.

So I guess the main benefit of separating data and structure the way XML and XSLT does is it means for the same XML, you can have different sets of XSLTs.  But wait...actually, you can't.  You embed the references for stylesheets for the XML file IN the XML file itself, i.e. the XML file says use this XSLT to render me.  So...if you want to switch XSLTs, you have to modify the XML file, which means you have to make the XML file content dynamically generated, which means you might as well use a fully-featured templating language on the server side.

Conclusion

XML+XSLT may have its uses, but general web applications is not one of them...