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.
Overview of SharePoint Client Side Rendering (CSR)
What is Client Side Rendering (CSR) in SharePoint? CSR is an API whereby Microsoft has pushed much of the process of rendering raw data as HTML off the server and onto the client (i.e. the browser) in the form of display templates (JavaScript) in SharePoint 2013 and later. It is a replacement for much of the XSLT that you may have written for previous versions of SharePoint to modify forms, views, and search results. This XSLT was processed on the server, and if you went nuts with this it could have a serious negative impact on the performance of your farm.
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.
A Light-weight CORS Wrapper for SharePoint REST
In this post I’m going to demonstrate a CORS Wrapper for postMessage operations, specifically in SharePoint, and intended to make CORS operations as simple as the Ajax operations we’re more familiar with. I’m going to develop the same simple pages I used in my last post, only using the CORS Wrapper this time. Then I’ll dump the CORS Wrapper on you. I’m not going to talk a great deal about the code, I’ve included a ridiculous number of comments in the code to explain what I’m doing.
Anyway, in my last post, I described the basics of using postMessage to do cross-origin web service calls in SharePoint. And I stressed that it is not that complicated. In just under 20 lines of JavaScript, I was able to expose the complete range of web services on a site collection to another site collection. And with another 10 lines of JavaScript I was able to consume one of these web services on another site collection.
And yet, in my experience, a lot of developers think this is too complicated and don’t want to deal with it. I think the reasons for this are twofold:
- SharePoint and it’s web services are already complicated. First, there’s a bunch of them, and they all take different parameters. And you need to set different headers depending on what you’re doing. And is it a GET, or POST, or MERGE. And they’re not very well documented, although that’s getting better. There are plenty of simple examples, but few complex ones (for instance, a lot is left to the imagination when it comes to filters or how lazy loading works).
- While postMessage does not add a ton of complexity, adding any complexity at all makes developers groan in agony (mostly because of reason 1).
Looks like an opportunity for some sort of CORS Wrapper or library. Deal with the complexity once, and forever more use the library to hide most if not all of the additional complexity.
REST Calls Across HNSCs (CORS)
First of all, what is CORS? It stands for Cross-Origin Resource Sharing, and if your eyes have already glazed over a little, don’t worry; it really isn’t that complicated. Say you have a site collection at https://intellipointsolutions.com, and it has some JavaScript that wants to load something from https://source.intellipointsolutions.com. The thing on https://source.intellipointsolutions.com is a cross-origin resource (or CORS), because https://intellipointsolutions.com is an origin and https://source.intellipointsolutions.com is a different origin. Now the origin is just the part of the URL up to the fully qualified host name (and port if a non-standard port is used), so https://intellipointsolutions.com/something and https://intellipointsolutions.com/somethingelse are NOT cross-origin resources, they both have the same origin of https://intellipointsolutions.com.