Msg#: 4469820 posted 8:46 pm on Jun 28, 2012 (gmt 0)
The task of dynamically generating XSLT with external settings is something best accomplished using a server-side language, such as Java or PHP or Perl or Python or whatever floats yer boat. PHP is actually quite good at it, since you merely need to add <?php echo $depth; ?> where you currently have the number "2"
In situations where the content of the XML isn't sufficient to render it the way I like, I usually abandon XSLT altogether and parse the XML using something like "SimpleXML" [php.net...]
The selective display of certain XML nodes is also easier to do using a server-side parsing, rather than an XSLT solution.
That said, maybe a more sophisticated XPATH in your for-each might be able to select rows where the depth is what you desire. in XSLT.
But that's not the solution I'd recommend.
As a general, personal rule - though I realize many XML/XSLT-focused apps break this rule - I insist that XML is not a *storage engine*. Storing piles of data in XML and treating it like a database is a mistake. Trying to craft the equivalent of a "where clause" in XSLT is not easy, because honestly XSLT isn't the right tool for that kind of thing.
XML is, at its best, a carrier format. Your XML input should contain only what you wish to display, and nothing more. Then the XSLT can be "dumb", and do what it does best - mark up and transform the XML into something that looks nice in an HTML browser.
That means you should re-examine your data access strategy. The data can be stored in a SQL database, and queried to get just the rows you desire. That data can then be assembled as XML, and then pass that XML into your XSLT stylesheet.
Don't take this personally, but it bothers me when people use a wrench to bang in a nail. Using XSLT to filter & sort data is evidence that XML is being used wrong.
Msg#: 4469820 posted 1:58 am on Jun 29, 2012 (gmt 0)
LoL httpwebwitch. Considering that converting XML using XSLT is my bread and butter in the integration space it made me smile. Admittedly I use BizTalk applications which usually takes care of creating the XSLT for me. I do however agree that it is more efficient to extract only the data that is needed before creating the XML.
However regarding your issue Sotu if what you are getting is the XML and you've got no choice except to use that then first try having your logic constructed like the following and separate your select and your conditions.
If it's data that accumulates and grows, extracting only the needed data into XML is pretty much a requirement. Databases employ indexes (b-trees and such) to make queries fast. XML does not. When you have a 1-million line XML file, you'll see how true this is...
the biggest XML file I ever had to style up (with XSLT) was about 1.5Gb. It was the 8-minute page load times that convinced the client to pursue a more viable storage strategy