Parts 1 and 2 of the XSLT List View Web Part Best Practices described a procedure that sets you up with a Visual Studio Solution and a known-good XSLT file derived from SharePoint.
The benefits of this setup are two-fold:
- You can edit your XSLT in Visual Studio 2010. For any large XSLT file, Visual Studio is the right place to edit your XSLT, particularly when the rest of your project is in Visual Studio. Visual Studio gives you intellisense, syntax color-coding, and more importantly, a robust environment that respects your source code as sacred. SPD sometimes does funny things to your files.
- You can iteratively deploy and test your XSLT in-situ meaning, in place in SharePoint where it's really going to run in production. There are scores of great XSLT development tools on the market but none of them seem to understand the SharePoint-specific quirks of XSLT developed to run inside an XSLT List View Web Part.
This post describes a PowerShell script that automates the key step of uploading the XSLT file you are editing in Visual Studio to the Style Library of your test site in one click. This script streamlines the process so you can edit-upload-test in a tight iterative cycle in order to really do your XSLT development inside SharePoint.
Recall from part 2 that we configured the XSLT List View Web Part to use the "SpotNewsStyle.XSLT" file located in the Style Library. We did this by editing the web part properties and setting the XSL Link field to point to our custom XSLT file in the Style Library. This means we can iteratively tweak our XSLT file, upload the XSLT file to the Style Library, and test by just refreshing the browser. This faster, less invasive and safer than editing the web part every time. The PowerShell script below reduces the already quick process of uploading the XSLT file to the Style Library to one click.
The LoadStyle.ps1 script
The LoadStyle.ps1 script below (part of the sample "Spot" solution available here) is designed to reside in and be run inside the "Deploy" folder of the "Spot" Visual Studio solution. You will certainly need to edit this file to make it work in your environment. However, the changes you need to make should be obvious and straightforward. This script has the name and relative path to the custom XSLT file (SpotNewsStyle.xslt) and Css style file (SpotStyles.css) hard-coded. It copies those two files from where they reside to the current working directory. It then opens my test SharePoint server at the hard-coded URL http://vm01 and uploads both files to the Style Library.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction
"SilentlyContinue"
Start-SPAssignment -Global
Copy-Item ..\StylesAndScriptsModule\SpotNewsStyle.xslt . -Force
Copy-Item ..\StylesAndScriptsModule\SpotStyles.css . -Force
$spWeb = Get-SPWeb -Identity http://vm01/sites/spot/
$spFolder = $spWeb.GetFolder("Style Library")
$spFileCollection = $spFolder.Files
$xsltFile = Get-ChildItem -LiteralPath $(Get-Childitem SpotNewsStyle.xslt)
$xsltFileStream = $xsltFile.OpenRead()
$spFileCollection.Add(
"Style Library/XSL Style Sheets/SpotNewsStyle.xslt",
$xsltFileStream, $true)
$xsltFileStream.Close()
$xsltFile.Delete()
$cssFile = Get-ChildItem -LiteralPath $(Get-Childitem SpotStyles.css)
$cssFileStream = $cssFile.OpenRead()
$spFileCollection.Add("Style Library/SpotStyles.css", $cssFileStream, $true)
$cssFileStream.Close()
$cssFile.Delete()
Stop-SPAssignment -Global
After uploading to the Style Library, it deletes copies of the files that it created in the current working directory. It does this so you can run this script over and over and it will always get the latest new version from the Visual Studio directory.
The Development Process
With all these pieces in place, you may iteratively develop your XSLT file by:- In Visual Studio, edit your custome XSLT file and click "save"
- Switch tasks to your SharePoint Management Shell (PowerShell) and run the LoadStyle.ps1 script shown above.
- Switch task to your browser which should already have your SharePoint site open with the page that has the XSLT list view web part displayed.
- Press F5 to refresh the browser.
Conclusion
When you are developing XSLT for the SharePoint XSLT List View Web Part, you really only need to save your file, upload it to the Style Library, and refresh your browser in order to test it. These blog posts described how to streamline your development process to the bare essentials freeing you to repeatedly code-and-test iteratively in the most efficient manner possible. I hope it helps. <MC>
It`s perfect tutorial. Martin, thank you very much. I hope you will write same posts in future.
ReplyDeleteCan you recomend books\articles to learn more about using XSLT in SP2010?
Thanks for the post.
ReplyDeleteIs this possible to do without touching SharePoint Designer as in our production environment we do not have access to it.
I tried to export to a .webpart file but the view doesn't exist and I get an error when adding to page in production. Ironically when I use the same .webpart file in designer it creates the view for me :(
Any tips?
Also to throw another wrench in the mix, I can only use sandboxed solutions.
Cheers
If you can figure out some other way to get the initial, working XSL without using the SharePoint Designer trick, then yes. The steps in Part II only use SharePoint Designer to "harvest" the initial XSL that SharePoint generated so that you have a known-working staring point. I recommend you work with a non-production SharePoint 2010 development environement - an environment where you can bring all the tools to bear that you need to do your job. Get an exact copy of the List from production and create that list on your Development SharePoint farm. Then use SPD and the trick I described in Part II to get the XSL. When finished, you can deploy your solution to production without use of SharePoint Designer. Note that this XSL is tightly related to the specific list that contains the underlying data, but it is not tightly related to the specific site or farm.
ReplyDeleteThanks for the advice.
ReplyDeleteSince I don't own the environment I can't get the exact list (ListID) and its related views.
I decided to use the DataFormWebPart. It gives me a little more control and it doesn't rely on a view. I can completely configure everything with just 1 feature with module containing 2 files (.webpart file and XSLT).
The only potential drawback to this is that the ribbon isn't wired up but in my case it is not required.
Cheers
Reggie