Sign in Register
Go to solution
Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Thomas Kahn 602 posts 506 karma points
    Sep 21, 2009 @ 16:04
    Thomas Kahn
    0

    Unwanted XSLT caching when including XSLT's in other XSLT's?

    Hi!

    I'm having caching problems with my XSLT's. In this project I'm using XSLT includes for the first time and I'm suspecting this is what is causing my problems. In an XSLT I'm including two other XSLT's, like this:

        <xsl:include href="renderContentUnit.xslt"/>
        <xsl:include href="renderCase.xslt"/>

    The functions inside these includes are then used by the "mother"-XSLT:

                <xsl:choose>
                    <xsl:when test="string(umbraco.library:GetXmlNodeById($currentPage/data[@alias='topStory'])/@nodeTypeAlias) = 'caseDoctype'">
                        <xsl:call-template name="renderCase">
                            <xsl:with-param name="currentNode" select="umbraco.library:GetXmlNodeById($currentPage/data[@alias='topStory'])"/>
                        </xsl:call-template>
                    </xsl:when>

                    <xsl:otherwise>
                        <xsl:call-template name="renderContentUnit">
                            <xsl:with-param name="currentNode" select="umbraco.library:GetXmlNodeById($currentPage/data[@alias='topStory'])"/>
                        </xsl:call-template>
                    </xsl:otherwise>
                </xsl:choose>

    The problem is that the mother XSLT seems to cache the content of the included XSLT's. The macro parameters of the mother XSLT's are set to the default values (Cache By Page = checked and Cache Period = 0).

    The only way I have figured out to clear the cache is this:

    1. Remove the includes from the mother XSLT
    2. Save the mother XSLT
    3. Reload the page on which the mother XSLT is used (then of course getting an XSLT error)
    4. Paste the incudes back into the mother XSLT again
    5. Save and reload - now it works - the caching is gone

    This is a very "kludgy" way of doing it though and I would like to know if there's something else I can do? Altering the macro cache parameters? Using a different syntax for the includes?

    Thanks in advance!

    /Thomas Kahn

    Copy Link
  • Dirk De Grave 4541 posts 6021 karma points MVP 3x admin c-trib
    Sep 21, 2009 @ 16:13
    Dirk De Grave
    1

    Hi Thomas,

    It's indeed annoying, but I managed to get things working again just by saving the 'including' xslt again, for each change in the 'included' xslt's. So, i don't think you need the remove, save, paste, save pattern. A simple clicking on the save button of the 'includer' should be ok.

     

    Let me know if that works out for you as well.

    Cheers,

    /Dirk

    Copy Link
  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Sep 21, 2009 @ 16:56
    Douglas Robar
    2

    The <xsl:include> statement is very powerful, and also a bit annoying because xslt's are compiled when saving, but not every time they are run (which would defeat the purpose).

    So... if you update the include'd file, you must then open and save each xslt that relies on it so that it "knows" about the changes in the included file. But if you update the main xslt file (and not an included file) then you only need save the main xslt file.

    Some sort of dependency checker would be awesome, though I don't know if it's possible/practical.

    Personally, I make a note in the included file(s) that mentions which xslt files reference it so that I can open/save them when I update the include file. And I don't bother to open/save any main xslt files that aren't using the updated functions in my include'd file because not all the functions (errr, 'templates') are referenced by every macro.

    Make sense?

    cheers,
    doug.

    Copy Link
  • Thomas Kahn 602 posts 506 karma points
    Sep 22, 2009 @ 08:59
    Thomas Kahn
    0

    Thanks a million guys!

    So this is not a bug but rather a "feature" that has to do with compiling and performance. My main reason for using XSLT includes in this case was that I didn't want the same two functions (responsible for rendering page content elements) duplicated in 5-6 different places. If I want to alter a certain tag in a page content rendering function, I want to do that in one place only. The solution with an include solved this problem and was very elegant. But now I understand that it comes with a prize...

    Adding a dependecy checker, like you suggest Doug, would be very nice. Still I suspect that it would add a new dimension of complexity.

    Two scenarios:

    1. You have several edited and unsaved XSLT scripts open in your editor. Then you edit a script that is included in these scripts. If you where to implement some sort of auto re-save/recompile function, there's a riskt that you save changes in the including scripts that the user doesn't want to save.
    2. If the editing is done in an external editor (like Visual Studio), how would you trigger the re-save/recompile action?

    /Thomas Kahn

    PS. Doug: You always make sense! :-)

    Copy Link
  • Janusz Stabik 37 posts 59 karma points
    Apr 01, 2011 @ 11:15
    Janusz Stabik
    0

    Thanks Doug this just saved me exactly the same problem.

     

    Copy Link
  • Chriztian Steinmeier 2798 posts 8788 karma points MVP 8x admin c-trib
    Apr 02, 2011 @ 19:25
    Chriztian Steinmeier
    0

    Hi everyone,

    This was taken thoroughly care of once and for all by Pete Duncanson's Life-Saving package: XSLTouch.

    Install and forget - it's that simple!

    /Chriztian

    Copy Link
Please Sign in or register to post replies

Write your reply to:

Draft