I'm working on a big solution, and on one of the pages I have a template that used 12 XSLT-macros. It's made that way because the macros can be used on other templates and pages as well, so I need to divide my functionallity up in 12 macros. In all of these 12 macros I'm actually using content from a custom made XSLT-extension, that gives me some XML. This means that in all of the macros I'm calling the extension like this:
This means that I'm calling the same extension 12 times on that page, which is kind of stupid. Therefore I have made another xslt-file called "myDataSource.xslt". In this xslt-file I'm creating the "MyDataSource"-variable just like above. When I'm doing this I can then include the xslt-file on all of the other 12 macro, instead of calling the extension in every file.
But heres my question:
What's the best way of including the general myDataSource.xslt-file in the other xslt-files? I can see two ways:
<xsl:include href="myDataSource.xslt"/>
or
<xsl:import href="myDataSource.xslt"/>
Both of the methods work just fine, but is one of the ways performing better than the other? And is this approach even performing better than calling the extension in all of the 12 macros(In my head it's a lot better, but am I right)?
<xsl:include> is literally like if you cut and pasted the included stylesheet into the one with the xsl:include line in, so other than a small hit to actually find and read the stylesheet its not going to make any difference.
xsl:import is slightly more complicated in that it has a lower precedence than the importing stylesheet, so if there are conflicting templates it may take longer to work out which one to call.
<xsl:include> allows you to include one stylesheet into another. The included stylesheet's templates will have the same default priorities and import precedence as the including stylesheet.
<xsl:import> offers the same, but the import precedence of elements in an imported stylesheet is always less than that of the importing stylesheet.
For me I use <xsl:import> when I have re-usable <xsl:template>s.
But if I use the xsl:include, then all of the content in myDataSource.xslt is "pasted" right into the file that I'm including it in right? Wouldn't this result in 12 calls to the extension, just like if I had created the variable in each of the 12 files? Or am I misunderstanding something now?
Yes it would include the XSLT multiple times (12) - there's no way to get around that. Instead could you cache the value that is returned from the custom extension? or not even cache it, but store it in a HttpItem for the remaining life of the page-cycle.
String key = "WhateverYouWantToCallIt";
if (HttpContext.Current.Items.Contains(key) && HttpContext.Current.Items[key] != null)
{
return (XPathNodeIterator)HttpContext.Current.Items[key];
}
else
{
// get the datasource here
XPathNodeIterator x;
// store it in a HttpItem
HttpContext.Current.Items.Add(key, x);
return x;
}
I'm making an assumption that you're using an XPathNodeIterator - but you get the general idea!
Having the .net code add in the references to the extensions is lightening fast so don't worry about that.
If your datasource does not change for the life cycle of the page then you can include it once as a global variable in a include'd xsl file which I "think" is how you are describing it above?
As for general performance of XSLT it is safe to say it is amazingly quick, the biggest issue you can have with it is dodgy xpaths which force the Transform engine to do lots of needless searching for nodes (using "//mynode" is a classic of this). Other than that it is safe to simply ignore XSL performance until you really, really, really need to start worrying about it.
For the record I always us xsl:include and often have my includes include other includes, all helps makes the code nice and modular and easy to update.
Best performance: xsl:include or xsl:import?
Hi all
I'm working on a big solution, and on one of the pages I have a template that used 12 XSLT-macros. It's made that way because the macros can be used on other templates and pages as well, so I need to divide my functionallity up in 12 macros. In all of these 12 macros I'm actually using content from a custom made XSLT-extension, that gives me some XML. This means that in all of the macros I'm calling the extension like this:
This means that I'm calling the same extension 12 times on that page, which is kind of stupid. Therefore I have made another xslt-file called "myDataSource.xslt". In this xslt-file I'm creating the "MyDataSource"-variable just like above. When I'm doing this I can then include the xslt-file on all of the other 12 macro, instead of calling the extension in every file.
But heres my question:
What's the best way of including the general myDataSource.xslt-file in the other xslt-files? I can see two ways:
or
Both of the methods work just fine, but is one of the ways performing better than the other? And is this approach even performing better than calling the extension in all of the 12 macros(In my head it's a lot better, but am I right)?
/Kim A
Listening....
The two are slightly different
from http://p2p.wrox.com/xslt/67445-performance-xsl-import-xsl-include.html
Dan
Hi Kim,
In your case, you would use the <xsl:include>.
Difference between <xsl:include> and <xsl:import>? Read more here: http://xml.apache.org/xalan-j/xsltc/xsl_include_design.html
For me I use <xsl:import> when I have re-usable <xsl:template>s.
Cheers, Lee.
Found an example of when I use <xsl:import> ... see my code snippet for rendering media items: http://bit.ly/cAFVyR
Thanks for your answers guys.
But if I use the xsl:include, then all of the content in myDataSource.xslt is "pasted" right into the file that I'm including it in right? Wouldn't this result in 12 calls to the extension, just like if I had created the variable in each of the 12 files? Or am I misunderstanding something now?
/Kim A
Hi Kim,
Yes it would include the XSLT multiple times (12) - there's no way to get around that. Instead could you cache the value that is returned from the custom extension? or not even cache it, but store it in a HttpItem for the remaining life of the page-cycle.
String key = "WhateverYouWantToCallIt"; if (HttpContext.Current.Items.Contains(key) && HttpContext.Current.Items[key] != null) { return (XPathNodeIterator)HttpContext.Current.Items[key]; } else { // get the datasource here XPathNodeIterator x; // store it in a HttpItem HttpContext.Current.Items.Add(key, x); return x; }I'm making an assumption that you're using an XPathNodeIterator - but you get the general idea!
Cheers, Lee.
Having the .net code add in the references to the extensions is lightening fast so don't worry about that.
If your datasource does not change for the life cycle of the page then you can include it once as a global variable in a include'd xsl file which I "think" is how you are describing it above?
As for general performance of XSLT it is safe to say it is amazingly quick, the biggest issue you can have with it is dodgy xpaths which force the Transform engine to do lots of needless searching for nodes (using "//mynode" is a classic of this). Other than that it is safe to simply ignore XSL performance until you really, really, really need to start worrying about it.
For the record I always us xsl:include and often have my includes include other includes, all helps makes the code nice and modular and easy to update.
Hope that helps
Pete
is working on a reply...