Have you tried adding:

<xsl:param name="currentPage"/>

Before the 

<xsl:template match="/">

I can't see the $currentPage being defined in the included XSLT-file. Shouldn't it be there...

Yes if I do that though, it will work with the version being called directly from the macro, but now the ones that refrence it using the include now don't work.

I get this error:

Error loading XSLT Article/DisplayArticleGallery.xslt
The variable or parameter 'currentPage' was duplicated with the same import precedence.
   at System.Xml.Xsl.XslCompiledTransform.LoadInternal(Object stylesheet, XsltSettings settings, XmlResolver stylesheetResolver)
   at System.Xml.Xsl.XslCompiledTransform.Load(XmlReader stylesheet, XsltSettings settings, XmlResolver stylesheetResolver)
   at umbraco.macro.CreateXsltTransform(XmlTextReader xslReader, Boolean debugMode)
   at umbraco.macro.getXslt(String XsltFile)
   at umbraco.macro.loadMacroXSLT(macro macro, Hashtable attributes, Hashtable pageElements)

I think you want to define your $currentPage before including the xslt:

<!-- XSLT Template Includes -->
<xsl:param name="currentPage"/>
<xsl:include href="../Common/ToolboxLinks.xslt"/>
<xsl:template match="/">
  <!-- Some other stuff & logic -->
  <!-- Article tools -->
  <xsl:call-template name="toolboxLinks" />
</xsl:template>

Ah of course.

I think in that case I'd write an XSLT extension to reconstruct the currentPage variable in the second XSLT. If the $currentPage variable is null, then use the "currentPage" xml from the extension. I'm just not sure if you can test for null in XSLT?!

Or you could use a third XSLT that only defines the currentPage param and includes the ToolboxLinks one. Then you could call it directly.

Thanks Morten, I really thought that would solve it, but it didnt :(
The included versions now work fine, but the direct macro version doesn't.

I suppose that could be the last resort Sebastiaan to use another XSLT as like a proxy, but it's a shame if I can't just call the xslt include itself.

Anyone else want to suggest anything?

Warren

Excellent stuff Adz I tried your first suggestion by moving the <xsl:param name="currentPage"/> into the included XSLT file only and removing it from the other XSLT files that include/reference that XSLT file.

Great stuff. Karma given :)

XSL include get processed first when they are read in so they need any params you are going to use in templates to be defined in the include file.

I'm a big fan of having a include file of helpers which can save global variables, functions etc. Makes life so much easier if you start coding from the off to allow for that.

Pondering including a "helpers" XSL file in the best practise package I'm knocking together.

Pete

Hiya guys,
OK with Adz suggestion of moving the currentPage into the include worked fine until I updated my main XSLT with another include that will also work as a standalone macro.

It works perfectly fine as standalone macros, but the problem again now is that both of the included XSLT files now have currentPage in.

Suggestions again to get this to work please.

Thanks,
Warren :)

OK answering my own question - not ideally what I wanted to do but I added a wrapper XSLT file for the second item that was being included in the main XSLT file and pointed the macro to the wrapper file and not the included xslt file.

An example wrapper file:

<xsl:param name="currentPage" />

<xsl:variable name="boxName" select="/macro/boxName" />
  
<!-- XSLT Template Includes -->
<xsl:include href="Sidebar_LinkBox.xslt"/>

<xsl:template match="/">
    <xsl:call-template name="sidebarBox">
      <xsl:with-param name="boxName" select="$boxName" />
    </xsl:call-template>
</xsl:template>

Updated xslt include file (removed the <xsl:template match="/">)

<xsl:template name="sidebarBox">
    <xsl:param name="boxName" />
    <xsl:param name="boxItem" select="$currentPage/ancestor-or-self::root/node [@nodeTypeAlias='Settings']//node [@nodeTypeAlias = 'SidebarLinkBox' and @nodeName = $boxName]" />
    
    <div>
      <xsl:attribute name="class">
        <xsl:choose>
          <xsl:when test="$boxItem/data[@alias='centerText'] = 1">
            <xsl:text>sidebar-box center</xsl:text>
          </xsl:when>
          <xsl:otherwise>
            <xsl:text>sidebar-box</xsl:text>
          </xsl:otherwise>
        </xsl:choose>
      </xsl:attribute>

      <xsl:if test="$boxItem/data[@alias='image'] !=''">
        <img class="float-left" alt="$boxItem/data[@alias='header']" src="{$boxItem/data[@alias='image']}"/>
      </xsl:if>
      
      <h3>
        <xsl:value-of select="$boxItem/data[@alias='header']"/>
      </h3>
      <p>
        <xsl:value-of select="$boxItem/data[@alias='bodyText']"/>        
      </p>
      <a class="arrow-button" href="{$boxItem/data[@alias='linkLocation']}">
        <span>
          <xsl:value-of select="$boxItem/data[@alias='linkText']" />
        </span>
      </a>
    </div>
  </xsl:template>

That seems to me to be a perfectly valid and sensible solution Warren, why do you get a bad code smell?

is working on a reply...