Archive for the ‘Technical’ Category
SP 2013: Extending the SuiteBarDelegateControl by adding the Title Breadcrumb control
June 15th, 2013 by Tobias Zimmergren
Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren
Introduction
In one of my previous articles where we investigated some of the new and awesome delegate controls in SharePoint 2013. It walks you through some of the interesting DelegateControl additions that I was playing around with. On top of that I got a comment about how you could extend it further by adding the current site title in the Suite bar:
Sure enough, I took a dive into the Seattle.master to take a look at how the title is rendered and found the control called SPTitleBreadcrumb. This is the control that is responsible for rendering the default out of the box title in a normal SharePoint team site like this:
So to follow the question through and provide an answer to get you started, we’ll take a quick look on how we can build further on our old sample from the previous blog post and add the site title (including or excluding breadcrumb-functionality) to the Suite bar.
Investigating the out of the box Seattle.master
In the OOTB Seattle.master, the title is rendered using the following code snippet:
<h1 id="pageTitle" class="ms-core-pageTitle">
<SharePoint:AjaxDelta id="DeltaPlaceHolderPageTitleInTitleArea" runat="server">
<asp:ContentPlaceHolder id="PlaceHolderPageTitleInTitleArea" runat="server">
<SharePoint:SPTitleBreadcrumb
runat="server"
RenderCurrentNodeAsLink="true"
SiteMapProvider="SPContentMapProvider"
CentralAdminSiteMapProvider="SPXmlAdminContentMapProvider">
<PATHSEPARATORTEMPLATE>
<SharePoint:ClusteredDirectionalSeparatorArrow runat="server" />
</PATHSEPARATORTEMPLATE>
</SharePoint:SPTitleBreadcrumb>
</asp:ContentPlaceHolder>
</SharePoint:AjaxDelta>
<SharePoint:AjaxDelta BlockElement="true" id="DeltaPlaceHolderPageDescription" CssClass="ms-displayInlineBlock ms-normalWrap" runat="server">
<a href="javascript:;" id="ms-pageDescriptionDiv" style="display:none;">
<span id="ms-pageDescriptionImage"> </span>
</a>
<span class="ms-accessible" id="ms-pageDescription">
<asp:ContentPlaceHolder id="PlaceHolderPageDescription" runat="server" />
</span>
<SharePoint:ScriptBlock runat="server">
_spBodyOnLoadFunctionNames.push("setupPageDescriptionCallout");
</SharePoint:ScriptBlock>
</SharePoint:AjaxDelta>
</h1>
What we can see in this file is that there’s a lot of action going on to simply render the title (or title + breadcrumb). You can play around with this in tons of ways, both server-side and client side. In this article we’ll take a look at how we can extend the Suite bar delegate control from my previous article in order to – using server side code – modify the title and breadcrumb and move it around a bit.
Should you want to get the title using jQuery or client side object models, that works fine too. But we can save that for another post.
Adding the Title Breadcrumb to the Suite bar
I’m going to make this short and easy. The very first thing you should do is head on over to my previous article “Some new DelegateControl additions to the SharePoint 2013 master pages” and take a look at the “SuiteBarBrandingDelegate Delegate Control” section and make sure you’ve got that covered.
Once you’ve setup like that, here’s some simple additional tweaks you can add to your Delegate Control in order for the breadcrumb to be displayed in the top row of SharePoint. Modify the content of the “SuiteBarBrandingDelegate.ascx.cx” (the file in my previous sample is named like that, in your case it may differ) to now look something like this:
protected void Page_Load(object sender, EventArgs e)
{
// Register any custom CSS we may need to inject, unless we've added it previously through the masterpage or another delegate control...
Controls.Add(new CssRegistration { Name = "/_layouts/15/Zimmergren.DelegateControls/Styles.css", ID = "CssReg_SuiteBarBrandingDelegate", After = "corev5.css" });
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)
});
// Create a new Title Breadcrumb Control
SPTitleBreadcrumb titleBc = new SPTitleBreadcrumb();
titleBc.RenderCurrentNodeAsLink = true;
titleBc.SiteMapProvider = "SPContentMapProvider";
titleBc.CentralAdminSiteMapProvider = "SPXmlAdminContentMapProvider";
titleBc.CssClass = "suitebar-titlebreadcrumb";
titleBc.DefaultParentLevelsDisplayed = 5;
// Add the Title Breadcrumb Control
BrandingTextControl.Controls.Add(titleBc);
}
As an indication, the end-result might look something like this when you’re done. What we’ve done is simply copied the logic from the Seattle.master into the code behind file of our delegate control and set the “DefaultParentLevelsDisplayed” to a higher number than 0 so it’ll render the actual breadcrumb. By setting this value to 0, only the title will be displayed.
Then if you want to hide the default title, you can do that by using this small CSS snippet:
#pageTitle
{
display: none;
}
And it’s gone:
From there you should be able to take it onwards and upwards in term of the styling. I haven’t really put any effort into making it pretty here
Summary
With these small additions and changes to my original code samples you can make the title bar, including or excluding the breadcrumb, appear in the top bar instead of in the default title-area.
Additional important comments:
You may need to consider ensuring that the Site Map datasource is available on every page, including system pages for example. If it isn’t or you land on a page that don’t want to render your breadcrumb/title, it may not be able to properly render your navigation as you would expect it to. However that’s something to look into further from that point.
For example, by default the “Site Content” link will not render the full breadcrumb properly, but rather just say “Home”. In order to fix smaller issues like that, we can further extend the code logic a few lines and take care of those bits.
My recommendation:
Always make sure you consider the approach you take for any type of customization and development. For this specific case, we’ve already used some code-behind to display our logo in the top left corner, so we’ve just built some additional sample code on top of that to render the breadcrumbs. However should we only want to do that and not move further onwards with the logic from here – I would most likely suggest you do this using jQuery/CSOM instead to be “Office 365 compliant” and keeping your customizations to a minimum.
Hope you enjoyed this small tweak. And keep in mind: Recommendations going forward (however hard it’ll be to conform to them) are to keep customizations to a minimum!
Cheers, Tob.
- Posted in Technical
- 1 Comment
- Tags: Branding, Development, Featured, SharePoint 2013, SP2013
SP 2013: Getting started with the new Geolocation field in SharePoint 2013
March 30th, 2013 by Tobias Zimmergren
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 codevar 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
Upgrading your SharePoint 2010 Visual Studio projects and solutions to SharePoint 2013
March 24th, 2013 by Tobias Zimmergren
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:
To
/_layouts/15/images/
Path to the layouts folder
Make sure to not forget the general layouts path:
To:
/_layouts/15/
Path to the ControlTemplates folder
Also make sure to replace the following paths:
To:
/_controltemplates/15/
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
- 20 Comments
- Tags: Development, Featured, SharePoint 2013, SP2013
SP 2013: Duplicate field name was found after upgrading your SharePoint 2010 solutions to SharePoint 2013
March 21st, 2013 by Tobias Zimmergren
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
SP 2013: Tip – Change the "SharePoint" text in the top left corner.
January 20th, 2013 by Tobias Zimmergren
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
- 13 Comments
- Tags: Branding, Customization, SharePoint 2013, SP2013
SP 2013: Some new DelegateControl additions to the SharePoint 2013 master pages
January 19th, 2013 by Tobias Zimmergren
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
- 27 Comments
- Tags: Branding, Customization, Featured, SharePoint 2013, SP2013
SP 2013: Measuring performance on the JSLink property in SharePoint 2013
December 28th, 2012 by Tobias Zimmergren
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
- 11 Comments
- Tags: Client Side Rendering, Featured, JavaScript, Performance, SharePoint 2013, SP2013
SP 2013: Searching in SharePoint 2013 using the REST new API’s
December 26th, 2012 by Tobias Zimmergren
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
SP 2013: The HTTP header ACCEPT is missing or its value is invalid – solution
December 26th, 2012 by Tobias Zimmergren
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
- 15 Comments
- Tags: Client Object Model, SharePoint 2013, SP2013
SP 2013: Using the JSLink property to change the way your field or views are rendered in SharePoint 2013
December 25th, 2012 by Tobias Zimmergren
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' /> " + 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' /> " +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' /> " + 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
- 18 Comments
- Tags: Client Side Rendering, Featured, JavaScript, SharePoint 2013, SP2013

