Archive for the ‘Technical’ Category

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

SharePoint 2013 comes with tons of enhancements and modifications to previous versions of the product. One of the cool features I’ve played around with lately is the Geolocation field. Back in 2010 I wrote a custom-coded solution for displaying location information in our SharePoint lists, integrating some fancy-pants Google Maps – in SharePoint 2013, a similar field exist out of the box.

In this article I’ll mention what this field does, a sample of creating and using the field, getting and setting the Bing Maps keys to make sure our maps are properly working and displaying.

Introduction to the Geolocation Field

I’ll showcase what the Geolocation field can do for us in a SharePoint list. In the sample below I’ve used a list called "Scandinavian Microsoft Offices" which contains a few office names (Sweden, Denmark, Finland and Norway). What I want to do in my list is to display the location visually to my users, not only the name and address of the location. With the new Geolocation field you can display an actual map, as I’ll show you through right now – skip down to the "Adding a Geolocation Field to your list" section if you want to know how to get the same results yourself.

A plain SharePoint list before I’ve added my Geolocation field

As you can see, no modifications or extra awesomeness exist in this list view – it’s a vanilla SharePoint 2013 list view.

The same list, with the Geolocation field added to it

When we’ve added the Geolocation field to support our Bing Maps, you can see that a new column is displayed in the list view and you can interact with it. In my sample here I’ve filled in the coordinates for the four Microsoft offices I’ve listed in my list.

Pressing the small globe icon will bring up a nice hover card kind of dialog with the actual map, with options to view the entire map on Bing Maps as well (which is essentially just a link that’ll take you onwards to the actual bing map):

Viewing an actual list item looks like this, with the map fully integrated by default into the display form:

And should you want to Add or Edit a list item with the Geolocation field, you can click either "Specify location" or "Use my location". If you browser supports the usage and tracking of your location, you can use the latter alternative to have SharePoint automagically fill in your coordinates for you. Compare it with how you check in at Facebook and it recognizes your current location and can put a pin on the map for you.

 

In my current setup I don’t have support for "Use my location" so I’ll have to go with the "Specify location" option – giving me this pretty dull dialog:

As you can see, you don’t have an option for searching for your office on Bing Maps and then selecting the search result and have it automatically insert the correct Lat/Long coordinates. But, that’s where developers come in handy.

Create a new Map View

Let’s not forget about this awesome feature – you can create a new View in your list now, called a "Map View", which will give you a pretty nice map layout of your tagged locations with pins on the map. Check these steps out:

1) Head on up to "List" -> "Create View" in your List Ribbon Menu:

2) Select the new "Map View"

3) Enter a name, choose your fields and hit "Ok"

4) Enjoy your newly created out of the box view in SharePoint. AWESOME

Adding a Geolocation Field to your list

Right, let’s move on to the fun part of actually adding the field to our list. I’m not sure if it’s possible to add the field through the UI in SharePoint but you can definitely add it using code and scripts, which is my preferred way to add stuff anyway.

Adding a Geolocation field using PowerShell

With the following PowerShell snippet you can easily add a new Geolocation field to your list:

Add-PSSnapin Microsoft.SharePoint.PowerShell

$web = Get-SPWeb "http://tozit-sp:2015"
$list = $web.Lists["Scandinavian Microsoft Offices"]
$list.Fields.AddFieldAsXml(
    "<Field Type='Geolocation' DisplayName='Office Location'/>",
    $true,
    [Microsoft.SharePoint.SPAddFieldOptions]::AddFieldToDefaultView)

Adding a Geolocation field using the .NET Client Object Model

With the following code snippet for the CSOM you can add a new Geolocation field to your list:

// Hardcoded sample, you may want to use a different approach if you're planning to use this code  
var webUrl = "http://tozit-sp:2015";

ClientContext ctx = new ClientContext(webUrl);
List officeLocationList = ctx.Web.Lists.GetByTitle("Scandinavian Microsoft Offices");
officeLocationList.Fields.AddFieldAsXml(
    "<Field Type='Geolocation' DisplayName='Office Location'/>", 
    true, 
    AddFieldOptions.AddToAllContentTypes);

officeLocationList.Update();
ctx.ExecuteQuery();

Adding a Geolocation field using the Javascript Client Object Model

With the following code snippet for the JS Client Object Model you can add a new Geolocation field to your list:

function AddGeolocationFieldSample()
{
    var clientContext = new SP.ClientContext();
    var targetList = clientContext.get_web().get_lists().getByTitle('Scandinavian Microsoft Offices');
    fields = targetList.get_fields();
    fields.addFieldAsXml(
        "<Field Type='Geolocation' DisplayName='Office Location'/>",
        true,
        SP.AddFieldOptions.addToDefaultContentType);

    clientContext.load(fields);
    clientContext.executeQueryAsync(Function.createDelegate(this, this.onContextQuerySuccess), Function.createDelegate(this, this.onContextQueryFailure));
}

Adding a Geolocation field using the Server Side Object Model

With the following code snippet of server-side code you can add a new Geolocation field to your list:

// Assumes you've got an SPSite object called 'site'
SPWeb web = site.RootWeb;
SPList list = web.Lists.TryGetList("Scandinavian Microsoft Offices");
if (list != null)
{
    list.Fields.AddFieldAsXml("<Field Type='Geolocation' DisplayName='Office Location'/>",
        true,
        SPAddFieldOptions.AddFieldToDefaultView);
}

Be amazed, its that easy!

Bing Maps – getting and setting the credentials in SharePoint

Okay now I’ve added the fields to my lists and everything seems to be working out well, except for one little thing… The Bing Map tells me "The specified credentials are invalid. You can sign up for a free developer account at http://www.bingmapsportal.com", which could look like this:

Get your Bing Maps keys

If you don’t have any credentials for Bing Maps, you can easily fetch them by going to the specified Url (http://www.bingmapsportal.com) and follow these few simple steps.

1) First off (after you’ve signed up or signed in), you’ll need to click on the "Create or view keys" link in the left navigation:

2) Secondly, you will have to enter some information to create a new key and then click ‘Submit’:

After you’ve clicked ‘Submit’ you’ll be presented with a list of your keys, looking something like this:

Great, you’ve got your Bing Maps keys/credentials. Now we need to let SharePoint know about this as well!

Telling SharePoint 2013 what credentials you want to use for the Bing Maps

Okay – so by this time we’ve created a Geolocation field and set up a credential for our key with Bing Maps. But how does SharePoint know what key to use?

Well that’s pretty straight forward, we have a Property Bag on the SPWeb object called "BING_MAPS_KEY" which allows us to configure our key.

Since setting a property bag is so straight forward I’ll only use one code snippet sample to explain it – it should be easily translated over to the other object models, should you have the need for it.

Setting the BING MAPS KEY using PowerShell on the Farm

If you instead want to configure one key for your entire farm, you can use the Set-SPBingMapsKey PowerShell Cmdlet.

Set-SPBingMapsKey -BingKey "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG"

Setting the BING MAPS KEY using PowerShell on a specific Web

Add-PSSnapin Microsoft.SharePoint.PowerShell

$web = Get-SPWeb "http://tozit-sp:2015"
$web.AllProperties["BING_MAPS_KEY"] = "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG"
$web.Update()

Update 2013-03-31: More examples of setting the property bag

I got a comment in the blog about having more examples for various approaches (like CSOM/JS and not only PowerShell). Sure enough, here comes some simple samples for that.

Setting the BING MAPS KEY using JavaScript Client Object Model on a specific Web

var ctx = new SP.ClientContext.get_current();
var web = ctx.get_site().get_rootWeb();
var webProperties = web.get_allProperties();

webProperties.set_item("BING_MAPS_KEY", "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG");
web.update();
ctx.load(web);

// Shoot'em queries away captain!
ctx.executeQueryAsync(function (){
    alert("Success");
},function () {
    alert("Fail.. Doh!");
});

Setting the BING MAPS KEY using .NET Client Object Model on a specific Web

// Set the Url to the site, or get the current context. Choose your own approach here..
var ctx = new ClientContext("http://tozit-sp:2015/");

var siteCollection = ctx.Site;
ctx.Load(siteCollection);

var web = siteCollection.RootWeb;
ctx.Load(web, w => w.AllProperties);
ctx.ExecuteQuery();

var allProperties = web.AllProperties;
ctx.Load(allProperties);

// Set the Bing Maps Key property
web.AllProperties["BING_MAPS_KEY"] = "FFDDuWzmanbiqeF7Ftke68y4K8vtU1vDYFEWg1J5J4o2x4LEKqJzjDajZ0XQKpFG";
web.Update();

ctx.Load(web, w => w.AllProperties);
ctx.ExecuteQuery();

So that’s pretty straight forward. Once you’ve set the Bing Maps Key, you can see that the text in your maps has disappeared and you can now start utilizing the full potential of the Geolocation field.

Summary

The Geolocation field is pretty slick to play around with. It leaves a few holes in terms of functionality that we’ll have to fill ourselves – but of course that depends on our business requirements. One example is that I rarely want to enter the coordinates into the Geolocation field myself, but I might just want to do a search and select a location which is the added and the coordinates populated into the field automatically, or use the (built in) functionality of "Use my location" – good thing we’ve got developers to fine-tune this bits and pieces

Enjoy.

• Posted in Technical
• 21 Comments
• Tags: Featured, Geolocation, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

Recently someone asked me about how to attack the major pain of upgrading their custom coded projects and solution from SharePoint 2010 to SharePoint 2013. Given that question and my experiences thus far I’ll try to pinpoint the most important things to consider when upgrading. There’s TONS of things you need to consider, but we’ll touch on the most fundamental things to consider just to get up and running. After that I’m sure you’ll bump into a few more issues, and then you’re on your way

Keep your developer tools updated

Visual Studio 2012 Update 1

The first step is to make sure that you’re running the latest version of Visual Studio 2012. As of this writing that means you should be running Visual Studio 2012 and then apply the Visual Studio 2012 Update 1 pack (vsupdate_KB2707250.exe) if it isn’t installed on your system already.

Visual Studio 2012 Office Developer Tools

The second step is to make sure you’ve got the latest developer tools for SharePoint installed. The package comes as an update in the Web Platform Installer which I urge you to have installed on your dev-box if you for some reason don’t already have it installed.

So, launch the Web Platform Installer and make a quick search for “SharePoint” and you should see the new developer tools there (note that the release date is 2013-02-26, which is the release date for the RTM tools):

Select the “Microsoft Office Developer Tools for Visual Studio 2012” and click “Add“. It will ask you to install a bunch of prerequisites which you should accept if you want to continue:

Let the tools be installed and the components updated. This could take anywhere from a few seconds to a few Microsoft minutes. It took about 5 minutes on my current development environment, so that wasn’t too bad.

Once the tools are installed, you are ready to get going with your upgrade.

Open your projects/solutions after upgrading Visual Studio 2012 with the latest tools

When the tools have been successfully installed and you open your solution the new tools will be in effect. If you’re opening a SharePoint 2010 project that you wish to upgrade to SharePoint 2013, you’ll get a dialog saying “Do you want to upgrade <project name> to a SharePoint 2013 solution? Once the upgrade is complete, the solution can’t be deployed to SharePoint 2010. Do you want to continue?”

Hit Yes if you get this dialog. If you want to upgrade your project to SharePoint 2013.

Once the project is loaded and have made all the necessary changes to the project files (which it now does automatically, unlike in the beta/preview tools where we had to do some manual tweaks), you should get an upgrade report telling you how things went. Hopefully there’ll be no Errors, only warnings and Messages.

If you check out the assembly references in your project that are pointing to any SharePoint assemblies, note that they have automatically been updated to the correct version of the SharePoint 2013 assembly:

Additional notes

If you upgraded without the latest version of the developer tools you only had the option to launch your projects in 2013-mode if you manually went into the .csproj file to modify (or add if one of them were missing) the following two lines:

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetOfficeVersion>15.0</TargetOfficeVersion>

This was true when the developer tools were in Preview/beta. But now when they’re released to RTM you shouldn’t be doing those manual hacks anymore. Trust the tools!

Tip: Some general code updates that may be required

When you deploy artifacts to the SharePointRoot folder in SharePoint 2013 they are now deployed to the /15 folder instead of the older /14 folder. SharePoint 2013 has a much better support for upgrade scenarios than previous versions of SharePoint (2010) which is why we’ve got the double hives. So, if you want to properly upgrade your solution you should also make sure to replace all the paths in your project from:

Path to the Images folder

From the images folder:

Path to the layouts folder

Make sure to not forget the general layouts path:

Path to the ControlTemplates folder

Also make sure to replace the following paths:

Well you get the general idea here.. Should you find paths pointing to your old 14-hive instead of the new 15-folder, make sure to change the path/url.

Tool-tip

As always, you will not be an efficient developer without the proper tools at hand to make the daily tasks easier.

If you enjoyed using CKS Dev for SharePoint 2010 development, you’ll still be able to enjoy some of that awesomeness by simply installing the CKS Dev tools for SharePoint 2010 on your Visual Studio 2012/SP2013 box. They seem to work fine on Visual Studio 2012 as well – so until there’s a proper update of the tools, you’ll be able to knacker some of your code with the old tools.

Do note that there’s certain features of the CKS Dev that doesn’t work fully, so should you encounter issues with the tool in various scenarios that’ll most likely be because they’re not engineered for Visual Studio 2012 (yet).

Deploy-time

After you’ve done enough tinkering you’ll be ready to rock this baby up on SharePoint 2013.

Enjoy!

• Posted in Technical
• 16 Comments
• Tags: Development, Featured, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

Okay so this will be a pretty short one, but hopefully help some folks that are upgrading their solutions from SharePoint 2010 to SharePoint 2013.

While developing fields, content types and the likes in SharePoint 2010, there’s always a few good rules and practices to follow. A good rule of thumb that I tend to stick to is to never use any reserved or system-name for your fields that you create. In this quick post I’ll talk about how to fix the "Duplicate field name was found" after you upgrade from 2010 to SharePoint 2013 and try to deploy and activate your feature(s).

In one of my projects that I am involved in, I was tasked to upgrade their existing SharePoint 2010 solutions to SharePoint 2013 – and this is where these problems hit us, hard.

A duplicate field name "Name" was found

If you have upgraded your solution from SharePoint 2010 to SharePoint 2013 and you deploy your code, only to find out that you are getting the notorious error message saying "A duplicate field name ‘fieldname’ was found" you might think you did something wrong in the deployment steps or otherwise failed to successfully upgrade your solution. What actually might have happened is a case of the "don’t use any reserved or system names, please" fever.

After some digging around our 30 projects, I found that the features and finally fields it were complaining about. While investigating the xml here, I noted that the "Name" was the failing factor. If we changed the Name property to something unique (hence, not a built-in field name), it seems to work out nicely.

Field xml for the SharePoint 2010 project

<Field
  ID="{7A1B35B9-C4F9-4181-82C3-A63DC31EB4BC}"
  StaticName="Notes"
  Name="Notes"
  Description="Short info on the tag"
  DisplayName="Notes"
  Type="Note"
  RichText="TRUE"
  RichTextMode="FullHtml"
  Group="My Awesome Fields"
  SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"/>

Field xml for the modified 2013 project, after modification

<Field
  ID="{7A1B35B9-C4F9-4181-82C3-A63DC31EB4BC}"
  StaticName="Notes"
  Name="MyAwesomeNotes"
  Description="Short info on the tag"
  DisplayName="Notes"
  Type="Note"
  RichText="TRUE"
  RichTextMode="FullHtml"
  Group="My Awesome Fields"
  SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"/>

What’s the difference?

So if you look at the two basic samples above, you can see that the small difference is what’s in the "Name" property. If I changed the value to something unique, it started working immediately.

But, doing this will of course bring up other questions that you need to take into consideration and think about.

• Is there any code reliant on your field’s name property?
• Will it break any functionality in your code or configured lists/views etc?
• What happens to data that potentially will be migrated from the old environment into the new environment? Can you map the data to the correct fields properly?

Summary

I thought I’d post this to save someone else from having to spend a few hours digging into the various bits and pieces of an enterprise project to find out where it breaks down after the upgrade. Should you encounter the error message in the title of this post immediately after upgrading your solutions, this may very well be the cause.

Please also make note that this solution is one solution to the problem. Perhaps there’s more solutions available to we can use to fix these issues. Should you know of any such solution, don’t hesitate to comment on the post and I’ll update it and give you the cred

SharePoint Server 2013 is an awesome product that is still uncharted territory for many organizations, but I’m seeing a huge increase in the adoption of 2013 locally and with that we’ll have plenty of time to dig into these fine bits of SharePoint magic

• Posted in Technical
• 2 Comments
• Tags: SharePoint 2013, SP201

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

In my previous post (http://zimmergren.net/technical/sp-2013-some-new-delegatecontrol-additions-to-the-sharepoint-2013-master-pages) I talked about how you could use the new delegate controls in the master page (seattle.master) to modify a few things in the SharePoint UI, including the text in the top left corner saying "SharePoint". If your goal is simply to change the text, or hardcode a link without the need for any code behind, you could do it even easier with PowerShell.

Changing the SharePoint text to something else using PowerShell

Before:

After:

PowerShell Snippet

$webApp = Get-SPWebApplication http://tozit-sp:2015
$webApp.SuiteBarBrandingElementHtml = "Awesome Text Goes Here"
$webApp.Update()

 

Enjoy.

• Posted in Technical
• 8 Comments
• Tags: Branding, Customization, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

In this post we’ll take a quick look at some of the new DelegateControls I’ve discovered for SharePoint 2013 and how you can replace or add information to your new master pages using these new controls, without modifying the master pages. This is done exactly the same way as you would do it back in the 2010 projects (and 2007), the only addition in this case are a few new controls that we’ll investigate.

New DelegateControls

Searching through the main master page, Seattle.master, I’ve found these three new DelegateControls:

• PromotedActions
• SuiteBarBrandingDelegate
• SuiteLinksDelegate

So let’s take a look at where these controls are placed on the Master page and how we can replace them.

PromotedActions Delegate Control

The PromotedActions delegate control allows you to add your own content to the following area on a SharePoint site in the top-right section of the page:

An example of adding an additional link may look like this:

So what does the files look like for these parts of the project?

Elements.xml

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
  <!-- DelegateControl reference to the PromotedActions Delegate Control -->
  <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/PromotedAction.ascx"
           Id="PromotedActions"
           Sequence="1" />
  
</Elements>

PromotedActions.aspx (User Control)

<!-- Note: I've removed the actual Facebook-logic from this snippet for easier overview of the structure. -->
<a title="Share on Facebook" class="ms-promotedActionButton" style="display: inline-block;" href="#">
    <span class="s4-clust ms-promotedActionButton-icon" style="width: 16px; height: 16px; overflow: hidden; display: inline-block; position: relative;">
        <img style="top: 0px; position: absolute;" alt="Share" src="/_layouts/15/images/Zimmergren.DelegateControls/facebookshare.png"/>
    </span>
    <span class="ms-promotedActionButton-text">Post on Facebook</span>
</a>

SuiteBarBrandingDelegate Delegate Control

This DelegateControl will allow you to override the content that is displayed in the top-left corner of every site. Normally, there’s a text reading "SharePoint" like this:

If we override this control we can easily replace the content here. For example, most people would probably like to add either a logo or at least make the link clickable so you can return to your Site Collection root web. Let’s take a look at what it can look like if we’ve customized it (this is also a clickable logo):

So what does the files look like for this project?

Elements.xml

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
  <!-- SuiteBarBrandingDelegate (the top-left "SharePoint" text on a page) -->
  <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/SuiteBarBrandingDelegate.ascx"
           Id="SuiteBarBrandingDelegate"
           Sequence="1" />
  
</Elements>

SuiteBarBrandingDelegate.ascx (User Control)

This is the only content in my User Control markup:

<div class="ms-core-brandingText" id="BrandingTextControl" runat="server" />

SuiteBarBrandingDelegate.ascx.cx (User Control Code Behind)

protected void Page_Load(object sender, EventArgs e)
{
    BrandingTextControl.Controls.Add(new Literal
    {
        Text = string.Format("<a href='{0}'><img src='{1}' alt='{2}' /></a>", 
        SPContext.Current.Site.Url,
        "/_layouts/15/images/Zimmergren.DelegateControls/tozit36light.png",
        SPContext.Current.Site.RootWeb.Title)
    });
}

SuiteLinksDelegate Delegate Control

The SuiteLinksDelegate control will allow us to modify the default links, and to add our own links, in the "suit links" section:

By adding a custom link to the collection of controls, it can perhaps look like this:

What does the project files look like for modifying the SuiteLinksDelegate? Well, here’s an example:

Elements.xml

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  
  <!-- DelegateControl reference to the SuiteLinksDelegate Delegate Control -->
  <Control ControlSrc="/_controltemplates/15/Zimmergren.DelegateControls/SuiteLinksDelegate.ascx"
           Id="SuiteLinksDelegate"
           Sequence="1" />
  
</Elements>

 

SuiteLinksDelegate.aspx.cs (User Control Code Behind)

public partial class SuiteLinksDelegate : MySuiteLinksUserControl
{
    protected override void Render(HtmlTextWriter writer)
    {
        writer.RenderBeginTag(HtmlTextWriterTag.Style);
        writer.Write(".ms-core-suiteLinkList {display: inline-block;}");
        writer.RenderEndTag();
        writer.AddAttribute(HtmlTextWriterAttribute.Class, "ms-core-suiteLinkList");
        writer.RenderBeginTag(HtmlTextWriterTag.Ul);
            
        // The true/false parameter means if it should be the active link or not - since I'm shooting off this to an external URL, it will never be active..
        RenderSuiteLink(writer, "http://timelog.tozit.com", "Time Report", "ReportYourTimeAwesomeness", false);

        writer.RenderEndTag();
        base.Render(writer);
    }
}

Solution overview

For reference: I’ve structured the project in a way where I’ve put all the changes into one single Elements.xml file and they’re activated through a Site Scoped feature called DelegateControls. The solution is a Farm solution and all artifacts required are deployed through this package.

Summary

In this post we’ve looked at how we can customize some of the areas in a SharePoint site without using master page customizations. We’ve used the good-old approach of hooking up a few Delegate Control overrides to our site collection. Given the approach of Delegate Controls, we can easily just de-activate the feature and all our changes are gone. Simple as that.

In SharePoint 2013 we can still do Delegate Control overrides just like we did back in 2007 and 2010 projects, and it’s still pretty slick. I haven’t investigated any other master pages other than the Seattle.master right now – perhaps there’s more new delegate controls somewhere else. Let’s find out..

Enjoy.

• Posted in Technical
• 22 Comments
• Tags: Branding, Customization, Featured, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

In one of my previous posts I talked about "Using the SPField.JSLink property to change the way your field is rendered in SharePoint 2013". That article talks about how we can set the JSLink property in our SharePoint solutions and how we easily can change the rendering of a field in any list view.

It’s pretty slick and I’ve already had one client make use of the functionality in their pilot SharePoint 2013 farm. However I got a comment from John Lui asking about what the performance would be like when executing the same iterative code over thousands of items. Since I hadn’t done any real tests with this myself, I thought it’d be a good time to try and pinpoint and measure if the client-side load times differ while using the JSLink property.

Measurements

The tests will be performed WITH the JSLink property set and then all tests will be executed WITHOUT the JSLink property set.

I’ve set up my scenario with various views on the same list. The total item count of the list is 5000 items, but we’ll base our tests on the limit of our views:

Test 1
View Limit	100
Test 2
View Limit	500

The results will be output with a difference between using the JSLink property and not using it. Should be fun.

Tools

I’be been using these tools for measuring the performance on the client:

Fiddler4, YSlow, IE Developer Tools

The code that will be executed will be the same JavaScript code as I had in my previous article.

SharePoint 2013 browser compatibility

If you intend to measure performance on various browsers, make sure you’ve pinned down what browsers are actually supported by SharePoint 2013. The following versions of browsers are supported:

• IE 10, IE 9, IE 8
• Chrome
• Safari
• Firefox

Let’s start measuring

Let’s start by taking a look at how I’ve done my tests and what the results were.

Testing methods

Each test was executed 100 times and the loading time result I’ve used for each test is the average of the 100 attempts. These tests are executed in a virtual environments so obviously the exact timings will differ from your environments – what’s mostly interesting right here though is the relative difference between having JSLink set and not set when rendering a list view, so that’s what we’ll focus on.

I’ve performed these tests on IE 10 and the latest version of Firefox. Since older browsers may handle scripts in a less efficient way than these two versions of the browsers, you may experience different results when using for example IE 8.

Results overview

SharePoint 2013 is pretty darn fantastic in its way that it renders the contents and pages. The measurements I’ve done here are based on the entire page and all contents to load. The chrome of the page (Navigation/Headers etc) loads instantly, literally in less than 25ms but the entire page takes longer since the content rendered for the list view will take considerably longer. Here’s the output…

Using 100 Item Limit in the View

Difference: 969 milliseconds

Conclusion

There’s not really much to argue about with the default 100-item limit. There’s a difference on almost one second, which is pretty bad to be honest. I would definitely revise these scripts and optimize the performance if I wanted quicker load times. However, if I changed the scripts and removed the rendering of images and used plain text instead, there was very little difference. So I guess it comes down to what you actually put into those scripts and how you optimize your JavaScript.

Using 500 Item Limit in the View

Difference: 529 milliseconds

Conclusion

The load times are naturally longer when returning 500 items, but the difference was smaller on a larger result set. I also performed the same tests using 1000 item limit in the view, and the difference per page load was between 500ms to 1000ms, essentially the same as these two tests. If your page takes 7-8 seconds to load without the usage of JS Link like these samples did in the virtual environments, I’d probably focus on fixing that before being too concerned about the impact the JS Link rendering process will have on your page. However, be advised that if you put more advanced logic into the scripts it may very well be worth your while to draft up some tests for it.

Things to take into consideration

• The sample script here only replaces some strings based on the context object and replaces with an image. No heavy operations.
• Replacing strings with images took a considerably longer time to render than just replacing text and render. Consider the code you put in your script and make sure you’ve optimized it for performance and scope your variables properly and so on.
• Take your time to learn proper JavaScript practices. It’ll be worth it in the end if you’re going to do a lot of client side rendering stuff down the road.
• If you’ve got access to Scot Hillier’s session from SPC12, review them!

Summary

Its not very often I’ve seen anyone use 1000 items as the item limit per view in an ordinary List View Web Part. Most of my existing configurations are using 100 or less (most likely around 30) items per page for optimal performance – however should you have larger views you should of course consider the impact the rendering will have if you decide to hook up your own custom client side rendering awesomeness.

You’ll notice the biggest difference between page load times if you’ve got a smaller item row limit in your view, simply because it looks like using the custom JS link property adds between 500 – 1000 milliseconds whether if I’m returning 100 items, 500 items or 2500 items in my view. Worth considering.

With that said – It’s a pretty cool feature and I’ve already seen a lot of more use cases for some of my clients to utilize these types of customizations. It’s a SUPER-AWESOME way to customize the way your list renders data instead of converting your List View Web Part (or Xslt List View Web Parts and so on) into Data View Web Parts like some people did with SharePoint Destroyer.. Err.. SharePoint Designer. For me as a developer/it/farm admin guy this will make upgrades easier as well (hopefully) as the list itself will be less customized, and only load an external script in order to make the customizations appear. Obviously I’m hoping for all scripts to end up in your code repositories with revision history, fully documented and so on – but then again I do like to dream

Enjoy.

• Posted in Technical
• 10 Comments
• Tags: Client Side Rendering, Featured, JavaScript, Performance, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

Search has always been a great way to create custom solutions that aggregate and finds information in SharePoint. With SharePoint 2013, the search capabilities are heavily invested in and we see a lot of new ways to perform our searches. In this post I’ll show a simple example of how you can utilize the REST Search API’s in SharePoint 2013 to perform a search.

REST Search in SharePoint 2013

So in order to get started, we’ll need to have an ASPX Page containing some simple markup and a javascript file where we’ll put our functions to be executed. The approach mentioned in this post is also compatible with SharePoint Apps, should you decide to develop an App that relys on Search. In my example I’ve created a custom Page which loads my jQuery and JavaScript files, and I’m deploying those files using a Module to the SiteAssets library.

Preview of the simple solution

Creating a Search Application using REST Search Api’s

Let’s examine how you can construct your search queries using REST formatting and by simply changing the URL to take in the proper query strings.

Formatting the Url

By formatting the Url properly you can retrieve search results pretty easily using REST.

Query with querytext

If you simply want to return all results with no limits or filters from a search, shoot out this formatted url:

will yield the following result:

Essentially we’re getting a bunch of XML returned from the query which we then have to parse and handle somehow. We can then use the result of this query in our application in whatever fashion we want. Let’s see what a very simple application could look like, utilizing the SharePoint 2013 rest search api’s.

ASP.NET Markup Snippet

As we can see in the following code snippet, we’re simply loading a few jQuery and JavaScript files that we require and we define a Search Box and a Button for controlling our little Search application.

<!-- Load jQuery 1.8.3 -->
<script type="text/javascript" src="/SiteAssets/ScriptArtifacts/jquery-1.8.3.min.js"></script>

<!-- Load our custom Rest Search script file -->
<script type="text/javascript" src="/SiteAssets/ScriptArtifacts/RestSearch.js"></script>

<!-- Add a Text Box to use as a search box -->
<input type="text" value="Awesome" id="searchBox" />

<!-- Add a button that will execute the search -->
<input type="button" value="Search" onclick="executeSearch()" />

<div id="searchResults"></div>

JavaScript logic (RestSearch.js)

I’ve added a file to the project called RestSearch.js, which is a custom javascript file containing the following code which will perform an ajax request to SharePoint using the Search API’s:

// in reality we should put this inside our own namespace, but this is just a sample.
var context;
var web;
var user;

// Called from the ASPX Page
function executeSearch()
{
    var query = $("#searchBox").val();

    SPSearchResults =
    {
        element: '',
        url: '',

        init: function(element) 
        {
            SPSearchResults.element = element;
            SPSearchResults.url = _spPageContextInfo.webAbsoluteUrl + "/_api/search/query?querytext='" + query + "'";
        },

        load: function() 
        {
            $.ajax(
                {
                    url: SPSearchResults.url,
                    method: "GET",
                    headers:
                    {
                            "accept": "application/json;odata=verbose",
                    },
                    success: SPSearchResults.onSuccess,
                    error: SPSearchResults.onError
                }
            );
        },

        onSuccess: function (data)
        {
            var results = data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results;

            var html = "<div class='results'>";
            for (var i = 0; i < results.length; i++)
            {
                var d = new Date(results[i].Cells.results[8].Value);
                var currentDate = d.getFullYear() + "-" + d.getMonth() + "-" + d.getDate() + " " + d.getHours() + ":" + d.getMinutes();

                html += "<div class='result-row' style='padding-bottom:5px; border-bottom: 1px solid #c0c0c0;'>";
                var clickableLink = "<a href='" + results[i].Cells.results[6].Value + "'>" + results[i].Cells.results[3].Value + "</a><br/><span>Type: " + results[i].Cells.results[17].Value  + "</span><br/><span>Modified: " + currentDate + "</span>";
                html += clickableLink;
                html += "</div>";
            }

            html += "</div>";
            $("#searchResults").html(html);
        },

        onError: function (err) {
            $("#searchResults").html("<h3>An error occured</h3><br/>" + JSON.stringify(err));
        }
    };

    // Call our Init-function
    SPSearchResults.init($('#searchResults'));

    // Call our Load-function which will post the actual query
    SPSearchResults.load();
}

The aforementioned script shows some simple javascript that will call the Search REST API (the "_api/…" part of the query) and then return the results in our html markup. Simple as that.

Summary

By utilizing the REST Search API we can very quickly and easily create an application that searches in SharePoint 2013.

This can be implemened in SharePoint Apps, Sandboxed Solutions or Farm Solutions. Whatever is your preference and requirements, the Search API’s should be easy enough to play around with.

Enjoy.

• Posted in Technical
• 15 Comments
• Tags: Client Object Model, Featured, REST, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

So just a simple tip in case anyone bumps into the same issue as I had a while back. Going from Beta to RTM, some things changed in the way you retrieve values using REST in the SharePoint 2013 client object model.

Description & Solution

In the older versions of the object model, you could simply use something like this in your REST call:

$.ajax(
    {
        url: SPSearchResults.url,
        method: "GET",
        headers:
        {
                "accept": "application/json",
        },
        success: SPSearchResults.onSuccess,
        error: SPSearchResults.onError
    }
);

As you can see the "headers" is specifying "application/json".

The fix is simply to swap that statement into this:

$.ajax(
    {
        url: SPSearchResults.url,
        method: "GET",
        headers:
        {
                "accept": "application/json;odata=verbose",
        },
        success: SPSearchResults.onSuccess,
        error: SPSearchResults.onError
    }
);

And that’s a wrap.

Summary

I hope this can save someone a few minutes (or more) of debugging for using old example code or ripping up older projects. I’ve found that a lot of examples online, based on the beta of SharePoint 2013, are using the older version of the headers-statement which inevitably will lead to this problem. So with that said, enjoy.

• Posted in Technical
• 13 Comments
• Tags: Client Object Model, SharePoint 2013, SP2013

Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren

Introduction

Recently I’ve had the pleasure (and adventure..) of upgrading a few SharePoint 2010 solutions to SharePoint 2013. One of the things that come up in literally every project I’m involved in, is the ability to quickly and easily change how a list is rendered. More specifically how the fields in that list should be displayed.

Luckily in SharePoint 2013, Microsoft have extended the SPField with a new proprety called JSLink which is a JavaScript Link property. There’s a JSLink property on the SPField class as well as a "JS Link" property on for example List View Web Parts. If we specify this property and point to a custom JavaScript file we can have SharePoint render our fields in a certain way. We can also tell for example our List View Web Parts to point to a specific JavaScript file, so they’re also extended with the JS Link property.

In this blog post I’ll briefly explain what the "JS Link" for a List View Web Part can look like and how you can set the property using PowerShell, C# and in the UI. I’ll also mention ways to set the SPField JSLink property, should you want to use that.

Final results

If you follow along with this article you should be able to render a similar result to this view in a normal Task List in SharePoint 2013:

You can see that the only modification I’ve made right now is to display an icon displaying the importance of the task. Red icons for High Priority and Blue and Yellow for Low and Medium.

Since it’s all based on JavaScript and we’re fully in control of the rendering, we could also change the rendering to look something like this, should we want to:

As you’ve may have noticed I haven’t put down a lot of effort on styling these elemenbts – but you could easily put some nicer styling on these elements through the JavaScript either by hooking up a CSS file or by using inline/embedded styles.

Configuring the JSLink properties

Okay all of what just happened sounds cool and all. But where do I actually configure this property?

Set the JS Link property on a List View Web Part

If you just want to modify an existing list with a custom rendering template, you can specify the JSLink property of any existing list by modifying it’s Web Part Properties and configure the "JS Link" property, like this:

If you configure the aforementioned property on the List View Web Part your list will automatically load your custom JavaScript file upon rendering.

Set the SPField.JSLink property in the Field XML definition

If you are creating your own field, you can modify the Field XML and have the property set through the definition like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">  
  <Field
       ID="{43001095-7db7-4219-9df9-b4b0f281530a}"
       Name="My Awesome Sample Field"
       DisplayName="My Awesome Sample Field"
       Type="Text"
       Required="FALSE"
       JSLink="/_layouts/15/Zimmergren.JSLinkSample/Awesomeness.js"
       Group="Blog Sample Columns">
  </Field>
</Elements>

Set the SPField.JSLink property using the Server-Side Object Model

Simply set the SPField.JSLink property like this. Please note that this code was executed from a Console Application, hence the instantiation of a new SPSite object:

using (SPSite site = new SPSite("http://tozit-sp:2015"))
{
    SPWeb web = site.RootWeb;
    SPField taskPriorityField = web.Fields["Priority"];

    taskPriorityField.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/AwesomeFile.js";
    taskPriorityField.Update(true);
}

Set the SPField.JSLink property using PowerShell

If you’re the PowerShell-kind-of-guy-or-gal (and you should be, if you’re working with SharePoint…) then you may find the following simple snippets interesting, as they should come in handy soon enough.

PowerShell: Configure the JSLink property of an SPField

$web = Get-SPWeb http://tozit-sp:2015
$field = $web.Fields["Priority"]
$field.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/Awesomeness.js"
$field.Update($true)

PowerShell: Configure the JSLink property of a Web Part

Note that this is what I’ve been doing in the sample code later on – I’m not setting a custom JSLink for the actual SPField, I’m setting it for the List View Web Part.

$web = Get-SPWeb http://tozit-sp:2015

$webPartPage = "/Lists/Sample%20Tasks/AllItems.aspx"
$file = $web.GetFile($webPartPage)
$file.CheckOut()

$webPartManager = $web.GetLimitedWebPartManager($webPartPage, [System.Web.UI.WebControls.WebParts.Pers
onalizationScope]::Shared)

$webpart = $webPartManager.WebParts[0]

$webpart.JSLink = "/_layouts/15/Zimmergren.JSLinkSample/Awesomeness.js"

$webPartManager.SaveChanges($webpart)

$file.CheckIn("Awesomeness has been delivered")

As you can see in the PowerShell snippet above we’re picking out a specific page (a Web Part page in a list in my case) and picks out the first Web Part (since I know I only have one Web Part on my page) and set the JS Link property there. This will result in the Web Part getting the proper link set and can now utilize the code in your custom javascript file to render the results.

So what does the JS Link JavaScript logic look like?

Okay, so I’ve seen a few ways to modify the JS Link property of a list or a field. But we still haven’t looked at how the actual JavaScript works or what it can look like. So let’s take a quick look at what it could look like for a List View Web Part rendering our items:

// Create a namespace for our functions so we don't collide with anything else
var zimmergrenSample = zimmergrenSample || {};

// Create a function for customizing the Field Rendering of our fields
zimmergrenSample.CustomizeFieldRendering = function ()
{
    var fieldJsLinkOverride = {};
    fieldJsLinkOverride.Templates = {};

    fieldJsLinkOverride.Templates.Fields =
    {
        // Make sure the Priority field view gets hooked up to the GetPriorityFieldIcon method defined below
        'Priority': { 'View': zimmergrenSample.GetPriorityFieldIcon }
    };

    // Register the rendering template
    SPClientTemplates.TemplateManager.RegisterTemplateOverrides(fieldJsLinkOverride);
};

// Create a function for getting the Priority Field Icon value (called from the first method)
zimmergrenSample.GetPriorityFieldIcon = function (ctx) {
    var priority = ctx.CurrentItem.Priority;

    // In the following section we simply determine what the rendered html output should be. In my case I'm setting an icon.

    if (priority.indexOf("(1) High") != -1) {
        //return "<div style='background-color: #FFB5B5; width: 100%; display: block; border: 2px solid #DE0000; padding-left: 2px;'>" + priority + "</div>";
        return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/HighPrioritySmall.png' />&nbsp;" + priority;
    }

    if (priority.indexOf("(2) Normal") != -1) {
        //return "<div style='background-color: #FFFFB5; width: 100%; display: block; border: 2px solid #DEDE00; padding-left: 2px;'>" + priority + "</div>";
        return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/MediumPrioritySmall.png' />&nbsp;" +priority;
    }

    if (priority.indexOf("(3) Low") != -1) {
        //return "<div style='background-color: #B5BBFF; width: 100%; display: block; border: 2px solid #2500DE; padding-left: 2px;'>" + priority + "</div>";
        return "<img src='/_layouts/15/images/Zimmergren.JSLinkSample/LowPrioritySmall.png' />&nbsp;" + priority;
    }

    return ctx.CurrentItem.Priority;
};

// Call the function. 
// We could've used a self-executing function as well but I think this simplifies the example
zimmergrenSample.CustomizeFieldRendering();

With the above script, we’ve simply told our field (Priority) that when it’s rendered it should look format the output HTML according to the contents in my methods. In this case we’re simply making a very simple replacement of text with image to visually indicate the importance of the task.

For examples of how you can construct your SPField.SPLink JavaScript, head on over to Dave Mann’s blog and check it out. Great info!

Summary

With a few simple steps (essentially just a JavaScript file and a property on the LVWP or Field) we’ve changed how a list is rendering its data. I’d say that the sky is the limit and I’ve already had one of my clients implement a solution using a custom JS Link to format a set of specific lists they have. What’s even better is that it’s so simple to do, we don’t even have to do a deployment of a new package if we don’t want to.

The reason I’ve chosen to do a Farm Solution (hence the /_layouts paths you see in the url’s) is that most of my clients still run Farm Solutions – and will be running them for a long time to come. And it wraps up a nice package for us to deploy globally in the farm, and then simply have a quick PowerShell script change the properties of the LVWP’s we want to modify and that’ll be that. Easy as 1-2-3.

Enjoy.

• Posted in Technical
• 17 Comments
• Tags: Client Side Rendering, Featured, JavaScript, SharePoint 2013, SP2013

Introduction

As most if not all of you already know, SharePoint 2013 and Office 2013 has been released to preview/beta and is available for download from Microsoft’s download centers. In this article I will briefly introduce some exciting changes that has been made to the SharePoint 2013 Business Connectivity Services framework. I’ve written a bunch of articles on BCS for SharePoint 2010, and now it’s time to continue that track and introduce the new features available in SharePoint 2013.

SharePoint 2013 – BCS with REST

In this article we’ll be taking a further look on the new Business Connectivity Services changes and additions in SharePoint 2013. I want to take a quick look and introduce how REST (Representational State Transfer) can be used and also how the Client Object Model can be utilized to communicate with your External Lists and BCS Entities.

So without further delays, let’s dig into the fantastic world of BCS and CSA (Client Side Awesomeness).

Business Connectivity Services and REST

Utilizing REST in BCS in your SharePoint 2013 environments isn’t really that big of a deal. It’s pretty straight forward. The first thing you should do is take a look at the following link which references the MSDN article about getting started with REST in SharePoint 2013.

So now that we know that REST is all about, we’re going to look at some code that will utilize REST to retrieve some data. In this sample I’ll continue to build on the solution I created in the previous article.

Final result will look like this

When our first snippet of code will be done, it’ll look something like this where our (in this case) App (page) is loaded:

So what the code will do is to pull out the images and links for the videos in the Telerik.Tv OData data source that we created in the previous article, and we’ll be doing this using the REST API’s.

In one big snippet, here’s what the REST call looks like in my App.js:

var context;
var web;
var user;

function sharePointReady()
{
    var requestUri = _spPageContextInfo.webAbsoluteUrl + "/_api/lists/getbytitle('Video')/items";
    jqxhr = $.getJSON(requestUri, null, onSuccessfullJSONCall);
    jqxhr.error(onErrorInJSONCall);
}

function onSuccessfullJSONCall(data) {

    var outputHtml = "";
    var results = data.d.results;
    var counter = 0;
    for (var i = 0; i < results.length; i++) {
        outputHtml += "<img src='" + results[i].ImageUrl + "' class='brick-image' />";
        counter++;

        if (counter >= 4) {
            outputHtml += "<br/>";
            counter = 0;
        }
    }

    $("#message").html(outputHtml);
}

function onErrorInJSONCall(err) {
    $("#message").text("Unawesome Error: " + JSON.stringify(err));
}

As you can see in the aforementioned code snippet, the calls to the REST API’s are pretty straight forward and I’m only making a quick call to fetch the data asynchronously using the $.getJSON() method.

Lets break it down in sections..

Script part 1: sharePointReady() method call

Since our project type (a SharePoint-hosted App) contains a stub for the Default.aspx page and the App.js files – a method called sharePointReady is defined in the App.js file and in the Default.aspx you have the following block which initiates the call to this method upon loading all other required awesome things:

    <!-- The following script runs when the DOM is ready. The inline code uses a SharePoint feature to ensure -->
    <!-- The SharePoint script file sp.js is loaded and will then execute the sharePointReady() function in App.js -->
    <script type="text/javascript">
        $(document).ready(function () {
            SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function () { sharePointReady(); });
        });
    </script>

(Optionally, you can put this code-block in the actual App.js file as well if you’d like – it’s up to you)

When SharePoint is done loading all the required stuff that it needs to function (sp.js), this method is executed. In this sample, I’m making a simple JSON call to the REST API using the syntax http://url/_api/lists/getbytitle(‘ListTitle’)/items which will get all list items in the list named Video:

function sharePointReady()
{
    var requestUri = _spPageContextInfo.webAbsoluteUrl + "/_api/lists/getbytitle('Video')/items";
    jqxhr = $.getJSON(requestUri, null, onSuccessfullJSONCall);
    jqxhr.error(onErrorInJSONCall);
}

Script part 2: On successful JSON callback, the following block is executed

We’re executing the onSuccessfullJSONCall() when our previous call is successful, and it’ll basically just parse the JSON result and push the items out in a simple HTML structure:

function onSuccessfullJSONCall(data) {

    var outputHtml = "";
    var results = data.d.results;
    var counter = 0;
    for (var i = 0; i < results.length; i++) {
        outputHtml += "<img src='" + results[i].ImageUrl + "' class='brick-image' />";
        counter++;

        if (counter >= 4) {
            outputHtml += "<br/>";
            counter = 0;
        }
    }

    $("#message").html(outputHtml);
}

Script part 3: In case of unawesomeness (failure)

In case the request failed, we’ll be handling that somehow in this method. In this case we’ll just be printing out the error message very quickly to the user:

function onErrorInJSONCall(err) {
    $("#message").text("Unawesome Error: " + JSON.stringify(err));
}

Summary

In this article we took a very quick look at how to get that first REST call working with SharePoint 2013 against our External List called “video”. With the returned result in JSON, we’re parsing it out and simply rendering the result in a more reader-friendly manner as pictures in a simple HTML grid.

So that’ll be it for the REST calls for now. It should get you started and set-up for creating a very simple application that utilizes REST for retrieving data from SharePoint.

More details on working with the REST API’s in SharePoint 2013 will follow later, including how to perform cross-domain queries.

Enjoy.

• Posted in Technical
• 9 Comments
• Tags: BCS, Client Object Model, Featured, REST, SharePoint 2013, SP2013