Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 2 down vote favorite
1

I've created some custom List Definitions (aka List Templates) and am provisioning List Instances of them into my site. I am then provisioning Pages (Wiki/WebPartPages) that refer to the lists/views that I've setup. I am trying to do this using the element and then specify only the properties I want to change, rather than exporting a (which isn't localizeable). I can work with the Title property fine, however, when I try to specify the XslLink property, my web part will not provision correctly:

<View List="Lists/MyList" BaseViewID="105" WebPartZoneID="wpz" ID="g_6BFC14DC_62A4_4512_A360_EB4A0FC4DBD1">
 <![CDATA[
  <webParts>
   <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
    <metaData>
     <type name="Microsoft.SharePoint.WebPartPages.XsltListViewWebPart, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />    
     <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
    </metaData>
    <data>
     <properties>
       <property name="Title" type="string">Me</property>
       <property name="XslLink" type="string">~site/Assets/xsl/my.xsl</property>
     </properties>
    </data>
   </webPart>
  </webParts>
  ]]>
</View>

For troubleshooting purposes, when I hard code the server relative url to my site (rather than using the "~site" reference), it also does not work. I check the contents of the page (using ?contents=1) and my web part is shown there, but likely as an "ErrorWebPart". I check the ULS logs and I get a vague "unexpected error" with DesignText and SourcePreabmle:DWP references.

Again, all this works fine if all I customize is the Title property, which makes me think my markup within the CDATA is correct. I've confirmed that the XslLink property (exposed via the DataFormWebPart from which XsltListViewWebPart ultimately derives) is, in fact, a string using ILSpy.

This also works fine if I get the content - using the "Save site as a template" functionality and extracting this page's contents into my feature.

Do I maybe need to use the old <WebPart> syntax instead of the newer <webParts>? Based on what I see in the Blog site template onet.xml (SiteTemplates\Blog\Xml\Onet.xml), it looks like the newer <webParts> is appropriate.

I see this in both a Sandboxed and Farm solution scenario.

thanks in advance!

share|improve this question
I was facing this same issue and never got the answer. Maybe this questions will help me out too. Eventually I got around it by assigning the XslLink in the <XslLink> element in the <View> element in the Schema.xml of the list. – Vardhaman Deshpande Apr 13 '12 at 5:20
Yeah, was going to do that, but my thinking is that in a Sandboxed Scenario (which I am in), I don't think this is possible. I am pretty sure a "View" .xsl needs to live in Template\Layouts\XSL, and cannot live in the virtual file system (SPWeb.Files) or a document library. – Brian Apr 13 '12 at 14:27
Hmm I don't think that property maps to the _layouts folder. Check out the following link: maulikdhorajia.blogspot.in/2011/06/… You can give it a try. – Vardhaman Deshpande Apr 13 '12 at 17:52
I'll try later, but that article you referred me to in the link in the comment just above here points out how to edit the XslLink property of an XSLT List View Web Part, not a "View" element's "XslLink". On top of that it's using SPD, not Schema.xml. – Brian Apr 13 '12 at 19:27
Hi Brian. Can you shed any light on a fix for this if you've found one? I'm also provisioning some XsltListViewWebParts to a page via a Module and can't seem to hook them up to my custom XSL file (which is deployed to the Style Library) using the XslLink property. I'm working with a sandbox solution so deploying the file to the _layouts folder unfortunately isn't an option. – Nick Larter Apr 24 at 7:39

1 Answer

up vote -1 down vote

Yeah, run into this before also, but with a Content By Query web part with custom XSLT. You can't use the ~token in the path, it just doesn't know what to do with it.

I don't know of a particular workaround for your situation, but for a custom web part that you are deploying, you can create a feature receiver that grabs the .webpart file, reads the XML, finds the token, replaces it with the actual site or site collection value, and saves the file back. I am not sure if there is a similar workaround that can be done for declarative lists and views.

share|improve this answer
1  
I find this to be inaccurate. In the ULS logs, I actually see that it can correctly translate my ~site token into the server relative path I need. In addition, in the original posting, I indicate that I tried hard coding the path, and that still doesn't work. Also, I have confirmed I can use the ~site token with the TitleUrl property and that works just fine. I realize I could provision the web part to the page using code in FeatureActivated if I was NOT in a Sandbox solution, but due to Sandbox constraints I cannot provision web parts to the page imperatively. – Brian Apr 13 '12 at 16:39
I never said you couldn't use the ~site token with other properties, as you mention they do indeed work fine. The token just doesn't jive with the XslLink property of these types of web parts. As for hard coding, have you tried placing in the Style Library and referencing from there? I seem to remember something about that property only supporting XSL files in that location. – Adam Toth Apr 16 '12 at 16:50
What I was saying is that I believe it does work with the XslLink property because I am seeing that it can translate the ~site token based on the exception logged in the ULS logs. I'll try the Style Library, but not optimistic. – Brian Apr 16 '12 at 17:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.