Ever had a list in SharePoint with a choice field that allowed multiple selections (i.e. checkboxes)? And with many things to choose from? See the picture below. In this particular case, you’d need to scroll down a page or two to see all of the choices. I’ve seen a lot of people try to solve this problem by making the choices wrap around inline instead of one per line, which is a fine solution if your choices are relatively small strings and there is a small enough number of them. But what if there are over 100 choices, and some of them are pretty big strings? That’s the problem I’m trying to solve with this Entity Editor Display Template.
Client-side Rendering
Star Ratings Display Template, Advanced CSR
In this post, I’m going to do a CSR field rendering template for a star ratings field. It’s just what it sounds like, give the user an opportunity to rate something with 0 to 5 stars, by clicking into an image of 5 stars. Under the hood it will just be a numeric field, but as much as possible I’d like the user to never see the number. Anywhere the field appears, they should see an image with the appropriate number of gold stars.
CSR on Steroids and the Amazing Technicolor Text Boxes, or CSR by Type
First things first, I want to apologize, because what I’m going to build in this post is pretty hideous. I’m going to introduce the concept of hooking up SharePoint CSR by type, rather than by internal field name (as most examples show). In this post, I’m going to show how to do CSR by Type, meaning override all fields of a given SPFieldType.
By way of background, yesterday I was trying to override the Client-side Rendering (CSR) of a Url field to allow it to take non-standard protocols like notes://. I didn’t feel like creating a site column so I applied it to the OOB site column called Url. So I setup my overrides like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | // override the render for the field called Url? var overrides = { Templates: { Url: { NewForm: editOverride, EditForm: editOverride, DisplayForm: displayOverride, View: displayOverride, } }, // insert the css OnPostRender: postRender, }; // register the template overrides, and to keep it simple, ignoring MDS SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrides); |
Here I’m overriding the rendering for the field called Url in all forms and views, right? Not so fast sparky! This worked a little too well. My override was getting called for other fields of type SPFieldUrl on the page that weren’t named Url. Ugh! Stepping through clienttemplates.js in the debugger, it quickly became apparent what was going on. In the fields object, you can specify CSR by internal field name, like I’ve been doing in previous posts in this series, but you can also specify CSR by type of field (using the client-side field type, so for instance Text for SPFieldText). This replaces the default rendering for all fields of that type.
That’s actually pretty cool, but the problem with it is that if you have a field whose internal name is the same as a field type, there is no way for you to override just that field. Bad Microsoft, programmer no donut! The rest of this post is going to be a quick demo I put together to demonstrate this functionality. I haven’t seen anything in the documentation for CSR, or any examples, that explain this functionality. Of course, the documentation for CSR is pretty thin.
An Accordion View, Custom List View Display Templates (CSR)
Implementing CSR display templates as a custom list view is one of my favorite things about Client-side Rendering in SharePoint. The reasons are twofold:
- First, we take full control of the view. We’re not just rendering some little piece (i.e. one field) of a form about which we’re not supposed to know anything.
- Even better, the deployment for this is very simple, in fact, it can be done entirely through the OOB SharePoint user interface…sort of!
The devil’s in the details and every SharePoint developer-related topic seems to include a “sort of”, but still custom list view display templates in SharePoint are pretty cool.
Tabbed Forms with Client-side Rendering (CSR)
In this post, we’re going to look at how to implement tabbed forms using CSR. Unlike our previous examples of field rendering, which generally depend on only one field, tabbed forms are going to depend on all fields in the form. For this reason, it makes sense that we’re going to inject our JavaScript by setting the JSLink property of a content type. Content types are, after all, basically just a collection of fields. There are some gotchas’, or at least things you should be aware of when setting the JSLink on a content type, which I’ll cover as I get to them.
Giving credit where it’s due, the code for this rendering template is an adaption of a tabbed forms rendering template that is available in the Office Developer Center samples for Client-side Rendering. I’ve included a link to that article in the references below. Like most tutorials, deployment is left up to you in that article, and it’s assumed you’ll just add content editors to your forms to get the script loaded. I’ll include a utility for setting the JSLink property on a content type, which is a much better solution with some caveats.
A Full-Fledged Client-side Rendering (CSR) Template, a Rating Field
In this post I’m going to write a more full-fledged CSR implementation, in that I’ll do the rendering and override template behaviors to deal with that rendering. It will be a simple rating field that let’s the user rate an item with a value from one to ten. I’m also going to override most of what you might want to override when implementing a display template to modify a form field, as in the NewForm, EditForm, DisplayForm, View, and OnPreRender callbacks plus Validation. So far, all of the CSR display templates I’ve shown for modifying form fields have been fairly evil. At least from Microsoft’s point of view. The reason is that I haven’t actually rendered anything, I’ve let SharePoint do the rendering and then manipulated the DOM afterward. In general, Microsoft would say, if you didn’t render it, don’t touch it. I can see their point, but then again if SharePoint gets me 80% of my customers requirements and I have to hack it a bit to get the other 20%, I’m not too proud.
Dynamic CSR (Client-side Rendering) Templates
As in, write the template once, drop it on the site, and then allow administrators to apply it to appropriate fields based on SPFieldType, in the browser, without ever having to edit a JavaScript file. So when I first started learning CSR, I was looking for it to be a replacement for custom field types from SharePoint 2010. But it isn’t really that. If I created an Autocomplete custom field type and deployed it, an administrator could then go through the browser and create as many instances of that field type as they wanted. But with CSR, the fields to which it applies are hard-coded in the JavaScript, which means if an administrator wants to apply a template to another field, she has to open the JavaScript and modify it. That’s not really comparable to custom fields. It’s just not as accessible for non-developer administrators. In this post, I’m going to show a utility page which implements what I’m calling Dynamic CSR, whereby an administrator can apply a template to a site column through the browser without even having to know that it’s implemented in a JavaScript file.
Creating an Autocomplete Client-side Rendering (CSR) Template
I’m going to do one more CSR Template that doesn’t really render anything, but rather changes something that SPClientTemplates actually renders, an autocomplete template. This one is a little less invasive, because it also doesn’t override the render method, so it doesn’t have to call the out of box renderer and be aware of the consequences of doing that. It can do that because it only cares about a single field, the one it’s going to modify, so it can safely do it’s work as soon as that field is rendered. That means that it can just override OnPreRender and OnPostRender.
Setting the JSLink Property of a Field Using JavaScript
In my last post I showed a utility page allowing you to set the JSLink property of a site column. In this post I’m going to dump the code on you, and then explain parts of it. It’s just a SharePoint wiki page with some JavaScript in it using the JavaScript Client-side Object Model (JSOM), so you can just drop it in the Style Library (or any document library really) and click on it to start using it.
Creating Cascading Lookups with SharePoint Client Side Rendering (CSR)
I have two goals in this post. First I want to show using CSR in SharePoint to do something cool (or at least useful), cascading lookups. Second I’d like to show a utility page that allows you to configure JSLink in a much better way than setting the JSLink property on a web part using the browser.
For the first goal, I’m going to create cascading lookup lists in a SharePoint form. I chose cascading lookups for a number of reasons:
- It’s a form customization that people frequently ask how to implement on forums like stack exchange (probably the single most common request).
- There is a nice implementation built into the jquery.SPServices library by Marc Anderson, which I’m going to use.
- It doesn’t require any custom rendering. Everything it does occurs after rendering. But it does have to override the render method, so it will need to pass through the rendering to the out of box client templates using the same technique as CSRSpy from my last post.