List View Web Parts and JSLink Display Template rendering issues

JSLink Display Template Rendering Issues

One of the greatest improvements in rendering technologies in SharePoint 2013, has been the introduction of JavaScript display templates (I’m sure some will argue that point though!). These templates give us the ability to change the way that fields, list views, search results etc display, through the use of JavaScript, HTML and CSS directly without the need to create an XSLT style sheet.

I’m quite sad in some way, as I spent a lot of time learning XSLT in order to provide nicely stylized renditions of list data for a lot of my clients. Indeed my session at SharePoint Evolutions 2013 was on just the subject of producing search based content roll-ups, with some heavy use of XSLT as well as looking at it’s replacement in 2013.

I’ve spent plenty of time over the last few months working with Search in 2013 and creating custom templates for the search results, but I hadn’t done much work with List views until recently.

Rather than re-create the wheel, I’m going to direct you to Wesley Prestons (@idubbs) excellent blog post on getting this working based on the session he did at SPC12.

But if you’re using those techniques on an MDS (Minimal Download Strategy) based site, then you will need to add some additional script handling in to make sure the rendering isn’t lost on the refresh.

So why the reason for this post if I’m not going to show you how JSlink works? Well the answer is, I’m going to show you where it doesn’t work at the moment, and you may just decide to jump right back to using XSLT.

One of the common customisations that I’m asked to do, is to create a dashboard page. Quite often this will be a collection of information from different lists, and very often they will each be styled very differently with each web part receiving a separate XSLT file to configure it.

If you’ve read through the comments on Wes’ post, you’ll see where the problem now arises. Depending on how your lists are configured, when you add a JSlink to one list view web part, it automatically affects any webpart on the page that uses the same list template type and BaseViewID.

So, if we’re using the Custom List template, and the allitems view from 3 separate lists, then all of those lists will have a ListTemplateType of 100 and a BaseViewID of 1.

The only way to change these values is to create your own List templates and views through a SharePoint solution and deploy it to the farm, thus breaking Microsofts suggestion that you should customise lightly if at all. (CMSWire: Microsoft-doesnt-advise-you-customize-sharepoint-2013)

So how does this work in practice?

For this example, I have two lists that are related to each other. The first is a list of Investment desks that cover a geographical area. In my example, I only have 2, UK and Japan. The second list is a list of funds assigned to either of these 2 desks.

Both fairly simple lists, created using the Custom list App and displayed on the page using the Allitems.aspx view.


In this example, the intention is to use the Desk list on the right as a dynamic navigation option, allowing the user to click on the name of a desk and to navigate to another Dashboard page, using the name of the desk as a query string option.

E.g. "/sitepages/deskdashboard.aspx?DeskID=UK"

Using the example templates that Wes has provided, I’m just using a custom Item rendering template to output this link into the page.


If we edit the Desk list item view web part and apply our JSLink file, We’ll see that our desk list has now been rendered simply as a list with an active link to the desk.

If we hover over our link, you see the status bar showing the correct URL.


However, if we take a step back and look at the whole page, You’ll see that the JSlink has also been applied to the fund listing with a DeskID that makes absolutely no sense.


So, what options do we have to work around this problem? The main consensus of opinion when you trawl around the internet is that you need to control the base template id by deploying a custom list template for each list that you want to amend the rendering of. But this frankly just isn’t a workable solution, especially when you understand that the majority of people doing this kind of customisation is going to be the Power-User/Middle Tier developer, that probably won’t have access to Visual Studio 2012.

And neither should they, as deploying a solution to resolve this issue definitely falls into the Sledgehammer/Nutcracker variety.

Luckily, Microsoft have left us the backdoor option. If you edit the Desk list web part and scroll to the miscellaneous section at the bottom where you add the JSLink, we do have the option to use server side rendering and with that comes the ability to reference an XSLT file in our site assets location.


You just need to ensure that you remove the JSLink and that you tick the "Server Render" option, otherwise SharePoint will just ignore your XSLT. At this point, all the old rules of XSLT development apply!

But… I’m not leaving this here as frankly I would rather use ONE type of rendering override in my projects. I’ll be digging deeper into the issues this has raised and trying to identify a supported way of having more than one overridden list view web part on the page. And when I do, I’ll be posting it here first!


02/09/2013 – In case you didn’t see the other link.. I have found a nice way to work around this issue in a fully supported way. Take a look at this blog entry here for the solution.

1 ping

  1. […] List View Web Parts and JSLink Display Template rendering issues […]

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.