Benefits of Client Side Rendering

Applies To: SharePoint 2013, 2016, Office 365

List View Client Side Rendering Primer: 2 of 5

About This Series

This series provides a brief overview of Client Side Rendering for List Views (often referred to as JSLink). Basic extension points and examples are included. The goal of this series is to get developers unfamiliar with this programming model quickly up to speed.

XSLT Alternative

Extensible Stylesheet Language (XSL) is the XML based language used to transform XML generally into either HTML or XML. XSL Transformations (XSLT) is the set of XSL templates to be used in specific transformations.

Benefits

  • Rendering performed Server-Side
  • Very Fast
  • Generally, great caching
  • Many traditional SP developers already have XSL knowledge

Limitations

  • Difficult to learn
  • Out Of The Box (OOTB) examples are overly complex
  • Impossible to debug
  • SP limits use to XSLT 1.0 which, even with the ddwrt functions, is not equivalent to the power of XSLT 2.0+
  • Office 365’s server distribution model negates many of the caching benefits seen in on premises versions (although still fast, large datasets and complicated transforms suffer from more performance issues in the cloud)
  • Non-XSL integrations (JavaScript, CSS, etc.) can be very difficult

XSLT is continuing to be supported (and even improved) in current versions of SharePoint. Many of the OOTB features continue to take advantage of it and there is little alternative in SharePoint 2010/2007.

XSLT continues to be an easy way to make minor tweaks to OOTB rendering. Additionally, there is no reliance on end user technologies (JavaScript and, depending on the complexity, modern browsers) since the rendering is performed on the server before being delivered to the client.

 

Client Side Rendering Benefits

  • Data retrieved Server Side
  • “Faster” page loads since only the data and the formatting logic is downloaded to the client and the markup is created there. Practically speaking, standard pages will not see much benefit from this.
  • Rapid development (debugging, simplified templates, etc.)
  • Many more JavaScript developers
  • Flexible Targeting
  • Easy integration with web services, JavaScript frameworks, etc.

Client Side Rendering Limitations

  • Potential for flashing based on client performance
  • Not fully supported – Display templates are used in some search web parts, but only the XSLTListView web part provides the JS Link property
  • Targeting multiple list views on the same page requires fragile or hacky workarounds

csrShim

csrShim is an open source solution that fills the gap of many of the limitations presented by OOTB client side rendering.

csrShim is an XSLT solution that can be used to:

  • Enable JSLink CSR with Content by Query web parts
  • Enable JSLink CSR with XMLViewer web parts supporting RSS, RDF, Atom, and Atom2
  • Can be easily extended to enable JSLink CSR with XMLViewer web parts and custom XML
  • Solve the multiple list views per page issue through simple parameter configuration

csrShim is available through GitHub at:
https://github.com/thechriskent/csrShim

jslink-pronunciation

Continue?

Alright, now you know why CSR is usually better than its predecessor, XSLT. You’ve gotten a small introduction to csrShim (although not required in any way for this series, the methods and techniques discussed for list view CSR will apply there too).

“CSR sounds awesome!!”, you scream. Well, since you’re super excited to give this thing a go and avoiding eye contact with your coworkers is probably a good idea right now, head on over to the next post in this series:

An Introduction to Client Side Rendering

Applies To: SharePoint 2013, 2016, Office 365

List View Client Side Rendering Primer: 1 of 5

About This Series

This series provides a brief overview of Client Side Rendering for List Views (often referred to as JSLink). Basic extension points and examples are included. The goal of this series is to get developers unfamiliar with this programming model quickly up to speed.

Introduction

Client Side Rendering (CSR) is a technology that provides extension points (templates) that use JavaScript to render the data to a SharePoint page. CSR is often referred to as JSLink in reference to the list view web part’s JS Link property. However, CSR can be used for far more than just rendering list views (although this is the most common use and the focus of this series).

Client Side Rendering was introduced with SharePoint 2013 and is fully supported in SharePoint 2016 and Office 365.

A Selective History of Drawing Data in SharePoint

sp-drawing-data-history

SharePoint 2007 incorporated the use of XSLT 1.0 to render list views through XML based web parts such as Content by Query web parts (CQWP) and DataView web parts (DVWP). This allowed developers to customize the display but required specialized knowledge, was very difficult to troubleshoot, and was very poorly documented. This approach is still available in all current versions; however, the usage is not generally recommended.

SharePoint 2010 brought several improvements to XSLT support and Microsoft embraced community sourced documentation. The most important introduction was the new XSLTListView web part that simplified individual list view display and provided a simpler (single stylesheet) usage of XSLT. The XSLTListView web part is still the recommended approach in 2010 and continues to be valid in all current versions.

SharePoint 2013 introduced Client Side Rendering. The primary focus of Client Side Rendering was on pre-defined display templates but an additional property was added to the XSLTListView web part, JS Link, that allowed the easy incorporation of JavaScript files wherever the list view was rendered. This allowed a more web standards based approach and opened the technology up to non-traditional SharePoint developers.

SharePoint 2016 (and Office 365) have not brought much more for Client Side Rendering. XSLT performance was improved illustrating their understanding of the wide usage of that technology still going forward. However, with the introduction of the new SharePoint Framework (SPFx), many use cases for CSR may be replaced. However, only the web part customization piece of SPFx has been released and only in Office 365 at the time this post was written. However, Microsoft has indicated that the framework will cover many of the other traditionally display template focused areas as well.

JSLink vs Display Templates

At a high-level, CSR can be broken down into two categories: JSLink and Display Templates. Although it is a bit of a misnomer to refer to them separately, the general usage of these terms can be defined as:

  • Display Templates
    • Templates used in Web Parts using Search
  • JSLink
    • Property on XSLTListView web parts
    • JavaScript files used for CSR

Display templates actually refers to predefined JavaScript associations with fields, lists, views, contenttypes, forms, and search results. In practical use, however, you’ll generally see these referred to as JSLink even though JSLink is only for the property association.

The focus of this series is on the use of JSLink in XSLTListView web parts.

Continue?

Now that you know the basic terms and have an idea of what this CSR/JSLink stuff are, it’s time to find out why you should use it. Check out the next post in this series:

Fixing Access Denied Issue with Adding Images to your Site Feed

Applies To: SharePoint 2013

The SharePoint Site Feed can be an easy tool for quick discussion and sharing (especially if you don’t have Yammer) and is included in several site templates by default. I ran into an issue that surprised me when attempting to post a reply. I had no trouble posting links and messages, but trying to add an image (clicking the camera icon) gave me an Access Denied error. Huh?

Turns out this isn’t an issue with the user’s account but rather with the App Pool Identity account. Taking a look at the documentation for Site Feeds and you’ll see this sentence:

“In SharePoint Server 2013, we recommend that the same service account be used for both the My Site host web application and the web application hosting the team sites.”

Well, crap. Turns out that I used different app pool accounts for the My Site web application vs my standard web application. So do we need to switch one or the other? Nope! Thankfully, I came across this helpful bit of powershell that will fix this issue for you:

$wa = Get-SPWebApplication "http://my.wirebear.local"
$wa.GrantAccessToProcessIdentity("wirebear\SP_Pool")

You’ll need to run this from the SharePoint Management Shell or use the Add-PSSnapin Microsoft.SharePoint.PowerShell command.

The first line gets the web application where your My Sites are hosted using the Get-SPWebApplication command. Obviously, you’ll need to specify your My Site host web application’s URL or name (instead of mine).

The second line is where the magic happens. The GrantAccessToProcessIdentity method grants permission to the specified App Pool account (use the service account running your problem web application’s app pool).

That’s it. No need to reset IIS or anything else. Just refresh the page with Site Feed on it and now you can upload photos. Here’s one to get you started:

581669_10200896834489112_601749778_n

Autosave in Visio

Applies To: Microsoft Visio

Did you know that unlike EVERY OTHER Microsoft Office program, Visio does NOT have autosaving turned on by default? If so, you probably found out the hard way like me.

Making Visio diagrams comes up pretty often when documenting workflows, server configurations, etc. Each of these diagrams always takes me far longer than it should and losing one that I have been working on makes we weep uncontrollably naked in the corner for 4+ hours. Here, I made a diagram:

Autosave Diagram

 

Generally I’m slapping Ctrl-S like it’s a gopher in one of those gopher slapping games or in some other situation where frequent slapping occurs. But for whatever reason when I’m trying to get those lines perfectly aligned to the grid or I’m making minor font tweaks, etc. I tend to lose my rhythm. Then if an errant update, a crash, or me dumbly closing the wrong window while ignoring the warning dialogs puts an end to my precious diagram, I go searching for the auto recovery files just like I would with Word or Excel.

But if you haven’t manually configured this, they are no where. All you’ll find in your AppData folder are shape caches and regret.

Turning on Visio Autosave

These instructions are for Visio 2013 but should generally work for 2010 and 2016 as well.

  1. Open Visio
  2. Click the File tab/menu in the upper left
  3. Choose Options
    FileMenu
  4. In the Options dialog, choose the Save section from the navigation on the left
  5. Check the box next to Save AutoRecover information every X minutes
    SaveOptions
  6. Click OK
  7. Reap the benefits of lower blood pressure

I’ve set mine to 5 minutes since I’m extra paranoid (The standard setting for other office programs is 10 minutes).

Go do this before you forget. It’s too late for me, perhaps you’ll do better.

post-36423-earn-this-gif-earn-it-Tom-Hank-nFkP

Debugging Sitecore dlls

Applies To: Sitecore, ASP.NET, Visual Studio

Recently I was experimenting with Sitecore’s Linq based search. I was having an issue with my facets (perhaps if I ever solve it I’ll write about that too) and I wanted to look into how these were actually created within the Sitecore code.

Using .NET Reflector I was able to decompile the Sitecore.ContentSearch.Linq dll and take a look at the code. (You can do this in the .NET Reflector Object Browser within Visual Studio if you have the .NET Reflector plugin installed). In order to debug it I had to select the Debug option in the same window. This generates the proper symbols and tells Visual Studio to use them. This is really awesome and you can begin walking through your code (Attach to Process w3wp.exe).

Unfortunately, I was unable to see the values of any variables. When attempting to evaluate them I was getting:

Cannot obtain value of local or argument ‘[varablename]’ as it is not available at this instruction pointer, possibly because it has been optimized away.

This is one of those rare cases where the message was actually related to the cause. In order to see those values of the decompiled Sitecore dlls and any other dlls in .NET you need to disable optimization.

“Great!” you shout while working alone in a darkened room full of loneliness. A quick trip to Google reveals you simply need to create an ini file with the same name as the dll with the following values:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

In my case I named this file Sitecore.ContentSearch.Linq.ini. Super easy, wow! But then nothing happens. Placing this file next to the dll file in the bin directory won’t accomplish anything. You will need to place it where the dll is actually living while the website is running.

To find this special place, attach to the process like normal and then choose DEBUG > Windows > Modules form within Visual Studio. This will show you all the dlls that are being used. Scroll down to the dll you want to target and copy the path (it’s probably somewhere in the Temporary ASP.NET Files) and open it in Windows Explorer. Copy your ini file there.

Stop debugging and re-attach to the process. Now you can see the values! Soon you will see the issue is probably your own code, but isn’t it nice to pretend it’s somebody else’s fault? You bet it is!

Hakin

Now you big time hacker!