Custom field types and rendering templates correlation with the new “Server Render” property of the ListFormWebPart

I worked on a few issues dealing with this subject recently and I thought I’ll share this out so that it can come handy for you.

If you have developed custom field types and custom rendering template that uses server-side OM to achieve a certain UI behavior or to perform some server-side validation… read on!  Well, if you have not implemented any such thing but still interested to know what’s this all about, be my guest

Scenario #1:

Let’s assume you have created a custom field type [SharePoint 2010: Creating Custom Field Types].  Created a site column using this custom field type.  You then create a custom content type via UI inheriting from the folder content type.  And associated this site column to the custom folder content type.  And then associated this custom folder content type to a list or a document library.

Now, you would expect that whenever you create a new folder using this custom folder content type in a list or document library, you’d see the site column (that was created from the custom field type) available as one of the folder property.  And that you’d be able to type some value in it and save.  Yes, that’s an expected expectation!  But you’d be surprised that though the site column is displayed, when you provide some value to it and hit Save to create the folder, the value you provided for the site column goes off and the folder never gets created!!!

Scenario #2:

Let’s assume you have designed a custom rendering template and exposed a custom rendering control that uses this template.  You have this template tied to a custom list definition you created.  You have some specific logic in terms of how the list items render in display, edit modes.  You would have obviously used the ListFieldIterator control to achieve certain or all parts of your requirements.  In this specific scenario reported to me, there was a logic to change the SPControlMode to Display even with the item is rendered in an edit form.  This logic was a server-side code and it wasn’t working!!!

Apparently, CSR [Client-Side Rendering] was at play here again and due to that server-side code failed to execute.  In SharePoint 2013, the recommended approach to customize rendering of a view or a field type is by using client-side rendering.  You can override the rendering template and do all sort of nice things in a much more neat manner.  Here are some articles to learn more about it.

How to: Customize a field type using client-side rendering

SharePoint 2013: Create custom Geolocation field type with client-side rendering

SharePoint 2013: Customize a list view by using client-side rendering

However, what if your requirement is to keep using the server-side logic for some reason (for e.g., to do some validation)?  This was the exact problem reported to me with the scenario mentioned above.  The solution turned out to be pretty simple.

Browse to the form where the field type is rendered.  Edit the page and you’ll see the form uses a ListFormWebPart to display the fields of the item.  Edit the web part to bring up the web part tool part properties section.  Here you’ll find the “CSR Render Mode” option under “Miscellaneous” section.  Just choose “Server Render (ServerRender)” for the “CSR Render Mode” option and that should address the above scenarios.

The “CSR Render Mode” property can also be set using server OM, CSOM and Windows® PowerShell using ListFormWebPart.CSRRenderMode property.

Cross post from https://blogs.msdn.com/sridhara