JSLink and Display Templates Part 6 – Creating View Templates and Deployment Options

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.

In order to get this to work you will need to make sure each of your “views” are encapsulated into separate JavaScript files (one view per file) and you will be uploading them into the Master Page Gallery (if any of you have read my Content Search Web Part series, or done any development with Search Results display templates, then all of this should be intimately familiar!).

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:

  • Content Type: JavaScript Display Template
  • 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)

MJH_VIEW_FILE

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!

MJH_VIEW

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.

The solution was adding a lightweight JavaScript “script loader” .. basically just a short JS file which then dynamically loaded in the reference JS from Azure.

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.

If you want to apply it carte blanche to all sites then a Custom Action to inject the JavaScript file using the ScriptLink element will allow you to push this onto every page without touching the master page, but be aware that this will also include plenty of back-end system pages (file dialogs, site settings, and so forth) so make sure you thoroughly test your code, and make it defensive enough that it doesn’t throw unexpected errors when the SharePoint libraries you expect to be there aren’t present.

If you are just mocking this up as an example then you can of course just upload the file manually, and for REALLY quick demos just copy-paste the JavaScript into a Script Editor Web Part!

  • GosuSalt

    Hi I’m have trouble setting the JSLink property a field. It was working Fri 21st Aug and it stopped working Mon 24. Now when I set the JSLink on my custom field, field.Update, then context.ExecuteQuery() I get Unknown Error. My context comes from the GetUserClient context and the user is a MS account user that has shared access to my O365 site.

  • Fabio Russo

    hi, i have a question.
    In the example “Part 5 – Creating custom List Views” you have show the change of an ListView, ok but is possible to select a single row and enable the ribbon for open the editForm?

    Or also, if the item is a document, is possible to show the “…” for see the preview of doc with OfficeWebApp?
    thank ‘s a lot

  • Trevor Germain

    Hi Martin,
    Great post series. I just wanted to point out that none of the images are working for this particular article. The other articles are fine.

    • Martin Hatch

      Yep, for some reason my Discus alerts weren’t firing. This is fixed now!

  • sweet p

    Thank you so much for this! I’ve had this issue where content editors/site owners want to display list view web parts designed using JSLink and CSR, but giving the end user the link to the javascript didn’t seem very user friendly. I just knew there had to be better way than having site owners manually edit the jslink on the web part and then I came across your post

    I had tried:
    1. Creating a view on a list and modifying the JSLink on the view, then trying to use that view in the list view web part. The list view web part would lose the jslink.
    2. Saving the list with a custom view pointing to the JSLink as a list template, then trying to create a list off that list template. That would lose the jslink reference too.

    With your steps, I can now target that list view template to any of my list types to create list views from. When I add a list view webpart/app part to a page now and select the custom view, it keeps that jslink reference