Well first of all .. OH MY GOD I AM SORRY .. this has taken an absolute age to get out of the door. There really isn’t any excuse (although I’m going to try and use the excuse of the birth of my second child along with crazy busy real-world-life getting in the way).
But .. I am back and should be blogging a little bit more frequently from now on! So .. the JSLink stuff .. where was I? (believe it or not this series has been going on for almost 2 YEARS!).. View Templates! Right!
In Part 5 we covered the ability to override the rendering of List Views, and from a developer perspective this was awesome, but it isn’t that useful from content editor’s perspective. The field-level overrides are easy enough to push through (because they can be applied to every single instance of a field at either the Site Column or Content Type scope) but the views tend to get in the way a little bit.
What we really need is the ability for someone who creates a new view to be able to pick one of our custom view templates, and that is exactly what we are going to do here. This is perhaps one of the least known features of the JSLink / Client-Side-Rendering approach for SharePoint 2013 and even people I have spoken to who have been doing JSLink development for a while now didn’t know about this.
Now you can put these files anywhere in the Master Page Gallery, my personal preference is to create yourself a new folder called “List Views” in the “Master Page Gallery > Display Templates” folder. The secret sauce however is the choice of Content Type:
- Name: <name of file>
- Title: <how it will appear when selecting the template>
- Target Control Type: View
- Standalone: Standalone
- Target Scope: <Relative URL where you want it to be used>
- Target List Template ID: <ID of list where view is available> (Optional)
To keep in line with my example in Part 5 I have added “MJH Announcement View” with a Target Scope of “*” (i.e. all sites) and a List Template ID of 104 (Announcement Lists)
Once this has been saved then if you browse to any announcement list and create a view then my new View type is available from the template selection screen!
Now finally a word on Deployment Options and this is relatively straightforward.
Where should I put my files … ?
The first thing is that your files need to reside in SharePoint. I had a conversation with @MarkStokes about this just the other week and he was trying to load his JS files from Azure Storage (so that you could upgrade multiple O365 tenancies from a single file). This didn’t work, as the absolute URLs in the JSLink properties weren’t being picked up and the files weren’t loaded.
In terms of where THAT file lives, the Master Page Gallery or Style Library are obvious choices as they include automatic permissions for all users to have limited read access. The JSLink properties then allow you to reference dynamic ~sitecollection URLs so you can get a reference URL to them relatively easily.
How do I get them there … ?
Again, this is really standard SharePoint stuff. If you are already using a No-Code-Sandbox-Solution then simply using a Module to push the files in makes sense. If you are instead using a Remote-Code provisioning approach (either using a Provisioning App or PowerShell approach) then you will be using CSOM to push the files in.
The only thing to bear in mind is what other assets rely on those JS files. If your JS file provides rendering overrides for a Site Column then deploy the file in the same feature / provisioning logic that you are using to provision your Site Column. If you want the end users to be able to turn it on and off for a given site then a separate Web Scoped feature makes plenty of sense.