I recently found one good use for not bashing XSLT right away. We were using JUnit and JUnitReport to do unit testing and reporting for our java using the Ant build tool. JUnit runs tests and can generate the output to xml. JUnitReport uses xslt to transform them to websites.
I simply hacked up Test::Harness with XML::DOM to generate a report for all my perl tests. Every night we run a few thousand perl and java tests, JUnitReport picks them both up without knowing or caring about the difference ... and generates an easy to browse report. I acutally found it VERY cool. Writing the test harness we pretty easy too. It only took me about 2 hrs to translate all the java harnesses. On the other hand, I tried to make one small change in the xslt, and having never done it before, I found it very, very annoying to follow. By the way, I had never done java before either. In summary, XSLT was fast, and worked with both languages without a problem so long as I used valid xml. > Alright, pretty smarmy. But unless you just happen to have > thousands of > XML documents sitting around on your hard drive, XSLT is a > solution in > search of a problem. Most of my data is in a RDBMS -- not XML. To > enhance the *need* for XSLT, some databases will now return XML. > That'san interesting idea. Instead of using a mature language like > Perl|Java|PHP, let's use something like XSLT to turn my data into > a web > page! It's new, shiny, and will solve the problem of TOO MANY people > knowing the other aforementioned languages. D'oh!
