XslLink vs. <xsl:import> in Data View Web Parts (DVWPs)

With a title like that, should I even pretend that this blog is about anything other than SharePoint?

I had a nice Skypversation with Jeremy Thake (@jthake) earlier today.  (Yes, today’s posts do have a certain @jthake skew.) Jeremy was having a problem with SharePoint Designer, and was hoping that I could help.

What Jeremy was doing was perfectly good practice: he wanted to store his XSL for DVWPs in separate XSL files for better manageability and reuse. To do this, he was adding a link in the DVWPs using the XslLink tag, something like so:

<XslLink>Style Library/XSL Style Sheets/Marc.xsl</XslLink>

What was happening was that every time he was saving the page with the DVWP on it, the file in the XslLink was also being saved, and the variables were being replaced with hard-coded values.  This didn’t sound familiar to me until Jeremy shared his screen and showed me that this dialog was popping up:

Ths important trick here is to click the Set Action… button and tell SharePoint Designer not to overwrite the existing, supporting file:

SharePoint Designer is trying to be helpful, but sometimes it isn’t.  When it was saving the external XSL file (in my example, Marc.xsl), it was corrupting it by hardwiring some of the values.

So, problem solved for Jeremy, but the more valuable part of the conversation was, for me, the following part where we discussed the merits of using XslLink versus <xsl:import>. I’ve been in the habit of using <xsl:import>. (Take a look at my prior post on how it works: Unlocking the Mysteries of Data View Web Part XSL Tags – Part 20 – <xsl:import>.) Probably because of my aproaching things from the Middle Tier, I just had never considered XslLink.

As Jeremy and I talked this through, we decided that <xsl:import> may actually provide more flexibility.  One of the things that I like about it is that you can include any number of separate external XSL files which contain your XSL templates.  By keeping the templates separated into different files by functional groupings, you can mix and match the ones you need in any instance. For instance, I usually have one called Utilities.XSL which are just general purpose templates (things like StripHTML or GetUserID) and others for things like date arithmetic functions.  Then I’ll have the templates which are specific to what I am doing with a particular list or set of lists in another XSL file.  This lets me use to grab as few or as many of the templates as I need, while continuing to manage them in one central location.

Another pretty big plus is that I’ve never seen this corrupting hardwiring going on with . We decided that the approach probably wins the day over XslLink for these reasons.  What do you think?