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.
Continue reading “Tabbed Forms with Client-side Rendering (CSR)”
Continue reading “Determining the Permissions of the Current User with REST”
In my last post I talked about the REST service calls of what I said at the time was possibly the ugliest SPA of all time. I wanted to do it with no dependencies, which means interacting with XMLHttpRequest directly, and that isn’t anybody’s idea of pretty. No dependencies also means no promises, and once you’ve programmed with promises for a while, working without them on networking code feels like a step backwards. In this post I’m going to rewrite the ugly SPA with the following changes:
- I’m going to use fetch for all REST calls. fetch is the future, or so they tell me. And it gives me a comfortable promises-based API.
- I’m also going to use “odata=nometadata” for all of my REST calls. As I mentioned in my last post, this may not work in a SharePoint 2013 environment unless Service Pack 1 has been installed and changes have been made to the SharePoint web.config to support JSON light. So if you’re on 2013 and it doesn’t support JSON light, you need to use “odata=verbose” as shown in my previous post.
As I work through the code, I’ll point out differences between “odata=nometadata” and “odata=verbose”. There really aren’t that many differences.
Continue reading “CRUD Operations for SharePoint Docs Using Fetch and REST”
In this post, I’m going to show how to do basic CRUD (Create, Read, Update, and Delete) operations with documents and SharePoint RESTful web services. Along the way, I’m going to flesh out possibly the world’s ugliest SPA (single page application). I’m only going to talk about the parts of the code that deal with Ajax and the RESTful web services, but I’ll attach the complete source. It’s a wiki page, so you can just drop it in a document library and open it to see how it works (it does try to work with a picture library with a title of Pictures in the current site, if you don’t have one, you can either create one or change the listTitle variable to be the title of another picture library in your site).
Continue reading “CRUD Operations for SharePoint Docs Using REST”
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.
Continue reading “A Full-Fledged Client-side Rendering (CSR) Template, a Rating Field”
Continue reading “Dynamic CSR (Client-side Rendering) Templates”
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.
Continue reading “Creating an Autocomplete Client-side Rendering (CSR) Template”
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.
Continue reading “Creating Cascading Lookups with SharePoint Client Side Rendering (CSR)”
So, what can you do with CSR? You can develop display templates to modify list forms, views, and search results. As you might imagine, that’s a pretty big topic, so this post (and several follow up posts) will talk about overriding the rendering of fields in list forms. Eventually, I plan to post about view and search display templates as well.
Continue reading “Overview of SharePoint Client Side Rendering (CSR)”