I usually try to see if I can “prepare” the XML for the XSLT so the code that gets the XML may perhaps be able to get the data from the database and merge it somehow with the rest of the XML. (But you need to profile that anyway!)

But I like that use of XSLT.

As an aside, I am hoping to shortly post something about using XSLT in MVC, and although the XSLT itself could be a controller (more like MVTemplate!), I am going to talk about it being used in a view. [There will be a post before that to explain why!]

To be fair I haven’t used them as often as I would like to, but I can remember at least one time where it became a life saver for hundreds of users of a large publishing system. There was nothing wrong with the code but the underlying system was supporting the dynamic access of hundreds of documents from the file system using XSL extensions, just to then only extract the title out of full article documents and build a URL to the page. The XSL profiler identified what part of the XSL framework was causing problems, and just by looking at the graphical report it became immediately apparent exactly what line of code was causing havoc.

We then just captured the title of articles in a database table and from then on instead of opening full XML documents, the XSL Extension returned a nodeset with the titles of articles and their respective URLs. We gained a 500% performance increase for that process.