What is Client-Side Rendering and Why Would I Use It?

Tim is a Senior Consultant at ThreeWill. He has 15 years of consulting experience designing and developing browser-based solutions using Microsoft technologies. Experience over the last 8 years has focused on the design and implementation of SharePoint Intranets, Extranets and Public Sites.

Sometimes I hear about new features in SharePoint, but it doesn’t immediately occur to me how they would be useful. I’ve heard of Client-Sider Rendering (CSR) for some time, but never really dug in to understand it until I was working on a recent project. Now that I understand it better, I’m sure I will use it much more often. Hopefully this brief explanation can help you better understand the power of Client-Side Rendering so that you can leverage it when it might be the best option.

Why Would I Use Client-Side Rendering?

SharePoint libraries and lists can be a great place to store information, but sometimes the out-of-box presentation of that information is not what is desired. For public facing sites in particular, there is usually a desire to display the content in a more engaging way than the standard interface. Client-Side Rendering is one possible solution to help you customize the display to your liking.

What Is Client-Side Rendering?

Client-Side Rendering (CSR) is javascript code that allows you to override the default SharePoint display by supplying your own html. Through the client-side context that is provided, you can dynamically integrate the data from the SharePoint list or library with your own custom html to manufacture the desired experience. CSR can be applied at several levels. For example, you can choose to override the display of one or two fields and allow the other fields to display as normal. Or maybe you want to change the background color of a numeric field called “Test Score” based upon the value (i.e. greater than 90 is green; between 70 and 80 is Yellow and less than 70 is red). Or maybe you need to customize the display in a more radical way. Maybe you want to display two items per row instead of the default behavior of one item per row. In this case, the default List View Header wouldn’t make sense, so you would likely override the Header. All of this is possible with CSR.

Let’s look at the sample below of default document library content displayed in 2 List View Web Parts. This should look familiar to those of you who have used SharePoint.


After applying Client-Side Rendering, I have transformed these two List Views to look a bit different.


As you can see in the Documents List View Web Part I, have overridden the Header to only display “Documents,” and I have overridden the item display to only display the name of the file (minus the checkbox a,nd icon). What you can’t really see and what is more significant than the UI changes is that I have also overridden the default click event so that this document opens in the SharePoint modal dialog.

So, when the link is clicked, I call a javascript function that formats the options object and then calls the out-of-box SharePoint modal dialog.

Here is the result:

For the Local Videos List View Web Part, I have overridden the header to display “Local Videos,” but I have also changed the display to display items per row instead of 1. I have also displayed a Thumbnail image that is a clickable link which launches the video in the SharePoint Modal dialog window.


As the name Client-Side Rendering implies, this transformation of the display all happens on the client-side. By including a reference to a javascript file in the JS link property of a web part on the page, I can relatively easy transform the display. In this scenario, I used the ~site token to reference the current site and stored my custom javascript file in the SiteAssets folder where it can be easily updated using SharePoint Designer.


Here’s a screen shot of some of the code. Note the references to different javascript functions to implement the html for the Footer, Header and Item.


I hope this has been useful to help you envision the value provided by Client-Side Rendering.

For a more detailed description of the options that are available, I recommend the following 3 blogs by Suhail Jamaldeen. He has provided a lot of useful detail that will be helpful if you determine Client-Side Rendering is a good solution for your problem.




read more
Tim CoalsonWhat is Client-Side Rendering and Why Would I Use It?

Using JavaScript IIFE’s and Promise Chaining with Lookup Fields

Lane is a Senior Software Engineer for ThreeWill. He is a strong technology expert with a focus on programming, network and hardware design, and requirements and capacity planning. He has an exceptional combination of technical and communication skills.
After reading Will’s excellent blog post about bootstrapping an Angular app with server side data, I wanted to share a trick that I recently used for bootstrapping a pure client side SharePoint app that dealt with lookup fields and promise chaining. While in this post I will also be using Angular, this technique should work with any framework that uses JavaScript promises (such as jQuery’s Defer or Kris Kowal’s Q).

In both SharePoint 2010 and 2013, the REST API will not return lookup field display values (unless you use the $expand query operator, but that only works if you know ahead of time which of the fields are lookups). Instead, the API will just return the ID of the lookup value, meaning you have to make another trip to the server to get the display value for the lookup field. However, when you are working with JavaScript promises, this can get messy quickly because of the asynchronous nature of promises and the need for following a synchronous series of steps to load list data from multiple lists.

In the JavaScript world, there is the notion of an IIFE (Immediately Invoked Function Expression). As it’s name implies, IIFE’s are a mechanism for immediately executing a function block without needing to have a function declaration (Ben Alman does a much better and far more detailed explanation of IIFE’s if you are interested). Using an IIFE inside of a promise’s .then() callback allows your code to be schema-agnostic while being much easier to read and (in my humble opinion) cleaner.

So let’s use a simple,. slightly contrived, example. Say we have two lists: Parent and Child. Parent has a lookup field that is bound to a field on the Child list. Using an IIFE inside a .then() callback to make the second trip to the server to get the Child’s lookup value would look something like this:

That’s it. Now you may have noticed that I contradicted myself because in the above code I have hard coded the ChildColumnId field, so it would have actually been much easier to just use the $expand keyword and avoid the need for the second round trip in the first place. I did this to make the code easier to understand. A more detailed example would be something like this:

You might have noticed that I also adding the result onto the parent object differently. In the first example, I added the ChildColumn field as a child object off the Parent;  In the second example, I added Child Columns as a property on Parent. Frankly, I just did this because it made the code on the second example a little easier to read (and write) but either approach is perfectly fine depending on your situation and how you are binding your view.

A working demo project for SharePoint 2013 can be downloaded here.

read more
Lane GoolsbyUsing JavaScript IIFE’s and Promise Chaining with Lookup Fields

Client Side Rendering in SharePoint 2013

Eric Bowden has over 19 years of software development experience around enterprise and departmental business productivity applications.

Lately, almost all of my SharePoint projects are using some aspect of Client Side Rendering (CSR).  This is a great capability introduced in SharePoint 2013 which allows you to make the best of SharePoint list views, while making minor (or major) updates as needed to fit your needs.  Check out this video from the SharePoint 2014 conference for an introduction to Client Side Rendering.

On my most recent project, building an extranet for a Law Firm, our client asked that the link which appears for certain document types to be opened in a new window, while other document types should continue to use the default behavior.  Here is a snip of javascript to illustrate the beginnings of my CSR.  Up to this point, the CSR that I’ve written contains code that you can find in most sample code for override of field rendering.

/* Client side rendering for modifications to SharePoint list views */

CustomCSR = {

renderLinkFilenameNoMenu: function (ctx) {

var html;

var fileTitle = ctx.CurrentItem.FileLeafRef;

if (fileTitle.indexOf(".") > 0) {

fileTitle = fileTitle.substring(0, fileTitle.indexOf("."));


//open files of type png in a new window
if (ctx.CurrentItem.File_x0020_Type.indexOf('png') == 0) {

html = "<a target='_blank' href='" + ctx.CurrentItem.FileRef + "' >" + fileTitle + "</a>";


else {

html = /* Get the default rendering for this field ??? */


return html;


(function () {

var overrideCtx = {};
overrideCtx.Templates = {};
overrideCtx.Templates.Fields = { "LinkFilenameNoMenu": { View: CustomCSR.renderLinkFilenameNoMenu } };


As you can see, there is an important element of my code that is missing:  the rendering for fields that I want to use the default SharePoint behavior.  Lucky for me, stackexchange user Jim Brown was kind enough to share the answer, shown below.

/* getDefaultFieldHtml from Jim Brown at http://sharepoint.stackexchange.com/questions/112506/sharepoint-2013-js-link-return-default-field-rendering */
getDefaultFieldHtml: function (renderCtx, field, listItem, listSchema) {

var renderingTemplateToUse = null;

var fieldRenderMap = {
<p style="padding-left: 60px;">Computed: new ComputedFieldRenderer(field.Name),
Attachments: new AttachmentFieldRenderer(field.Name),
User: new UserFieldRenderer(field.Name),
UserMulti: new UserFieldRenderer(field.Name),
URL: new UrlFieldRenderer(field.Name),
Note: new NoteFieldRenderer(field.Name),
Recurrence: new RecurrenceFieldRenderer(field.Name),
CrossProjectLink: new ProjectLinkFieldRenderer(field.Name),
AllDayEvent: new AllDayEventFieldRenderer(field.Name),
Number: new NumberFieldRenderer(field.Name),
BusinessData: new BusinessDataFieldRenderer(field.Name),
Currency: new NumberFieldRenderer(field.Name),
DateTime: new DateTimeFieldRenderer(field.Name),
Text: new TextFieldRenderer(field.Name),
Lookup: new LookupFieldRenderer(field.Name),
LookupMulti: new LookupFieldRenderer(field.Name),
WorkflowStatus: new RawFieldRenderer(field.Name)


if (field.XSLRender == '1') {

renderingTemplateToUse = new RawFieldRenderer(field.Name);

else {

renderingTemplateToUse = fieldRenderMap[field.FieldType];
if (renderingTemplateToUse == null)
renderingTemplateToUse = fieldRenderMap[field.Type];


if (renderingTemplateToUse == null)

renderingTemplateToUse = new FieldRenderer(field.Name);

return renderingTemplateToUse.RenderField(renderCtx, field, listItem, listSchema);


getDefaultFieldHtml (shown above) returns the html mark-up for the default presentation of any field.  Since this mark-up is often times very complex, such as for Office documents, it saves a lot of time and results in greater quality of code if I can simply re-use the mark-up that SharePoint provides.

Now that I have this handy method included in my javascript namespace, I can update my code to render the default html as follows:

html = CustomCSR.getDefaultFieldHtml (ctx, ctx.CurrentFieldSchema, ctx.CurrentItem, ctx.ListSchema);

As a quick enhancement, I’ve placed CSR on list view pages in SharePoint simply by adding a script editor block to the top.  This is an easy approach for a “one-off” modification to an existing list view.

However, it’s more common for CSR to be included as part of larger, deployed SharePoint projects and applications.  We have a great story for building and deploying robust applications for SharePoint on-premises and in Office 365.  Leave a comment below if you have questions or your own tips for deploying CSR for your project.

read more
Eric BowdenClient Side Rendering in SharePoint 2013

Tired of SharePoint People Picker? Have it Your Way!

Mike is a Product Manager for ThreeWill. He has a passion for solving problems, most notably through products or platforms. He has over 13 years of experience in product development and leadership with the latest and greatest Microsoft Technologies, as well as consulting and IT department and team management. He's willing to venture into technologies outside of the Microsoft universe if the situation demands it. Mike brings a dedicated to solving problems and providing applications that will enhance the scope and scale of your business, whether it be through building products, Sharepoint-based solutions, or customized content management systems.

When building an app for SharePoint 2013, it’s likely that a people-picker will be needed at some point.  Regardless of the chosen hosting model, there are challenges to using the standard People Picker control.  This is particularly true in the case where the app’s user interface has been implemented as a “naked” HTML page (as opposed to the Microsoft-provided Default.aspx page). While I’ve discovered there’s an alternate people-picker available, In the case of my app I had a legitimate interest in building my own.  In fact, to be a bit more precise, I had several goals:

  • Build a people picker that is hosted in a “naked” HTML page
  • Fully exploit the power of javascript and jQuery
  • Be able to take advantage of any of the numerous open-source javascript libraries that are avaiable

After some research and experimentation I settled on the following:

  • jQuery
  • Select2 –  a jQuery add-on that provides a replacement for select boxes – in particular it supports progressive search against a REST API
  • Bootstrap – a collection of tools for quickly building a responsive, web-based UI
  • SharePoint REST API

The HTML page I authored includes the following references:

<script type="text/javascript" src="../Scripts/libs/select2/select2.min.js"></script>
 <!-- Select2 CSS -->
 	<link rel="Stylesheet" type="text/css" href="../Scripts/libs/select2/select2.css" />
 	<link rel="Stylesheet" type="text/css" href="../Scripts/libs/select2/select2-bootstrap.css" />

Next, I added input type=’text’ to page.  Note that while Select2 works with select boxes in it’s most basic form, the control needs to be an input box of type text in order to exploit the built-in AJAX/REST search support.

<input type="text" id="peoplePickerDiv" class="form-control" />

Once my markup was in place I added the following function to bestow the “Select2” functionality on the input control:

function SetCustomPeoplePicker() {
     placeholder: "Search for a person",
     minimumInputLength: 3,
     ajax: {
         url: $.QueryString["SPAppWebUrl"] + "/_api/web/siteusers",
         dataType: "json",
         data: function (term, page) {
         return {
             "$filter": "substringof('" + term + "', Title)"
     results: function (data, page) {
       return { results: data.d.results };
     params: {
       contentType: "application/json;odata=verbose",
       headers: {
         "accept": "application/json;odata=verbose"
   id: function (person) { return { id: person.Id }; },
   formatResult: function (person) {
     return person.Title;
   formatSelection: function (person) {
     return person.Title;
   formatNoMatches: function () {
     return "No people found. (Case Sensitive)";
   escapeMarkup: function (m) { return m; },
   dropdownCssClass: "bigdrop"
   }).on('change', function (e) {
     // Access to full data

A few things to point out in the above function:

  • This code uses SharePoint’s RESTful endpoint for site users (/_api/web/siteusers)  to get the set of site users for the app web.
  • The data function supplies parameters to the AJAX/REST call; of particular importance is the use of the  OData $filter parameter.
  • The SharePoint-supplied  substringof() function is to populate the $filter parameter. Inexplicably, this function treats data in a case-sensitive fashion!
  • params and headers property must be supplied as shown above.
  • The id property must be supplied as shown above, otherwise the returned results will not be selectable.
  • Note that the change event handler demonstrates how to pull the selected value and its accompanying data.
  • The RESTful endpoint for pulling site users does not search through user accounts that have not logged into SharePoint yet (unlike the SharePoint people picker, which shows all accounts).

Building your own people-picker lets you “have if your way” and provide a rich set of functionality for “picking people” in SharePoint.

read more
Mike HomolTired of SharePoint People Picker? Have it Your Way!

Web API, Azure, and Intergalactic Reuse

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.

I’ve been programming for a long time (really, since 1981) and in that time I’ve seen a lot of things come and go on the topic of “reuse”. Without rehashing all of the details, I think it is safe to say that many of those schemes didn’t live up to their promise simply because they were limited in scope to a certain platform and/or a certain language. To put it another way: most of these reuse options were language-based compile-time reuse, not runtime reuse. Given the connected, multi-platform world we find ourselves in, the notion of runtime reuse is possible, practical, and in some cases desirable.

I’m excited to be working on some new research items here at ThreeWill, and a big part of that is learning and working with the capabilities of Azure. This post (and, hopefully some future posts), will document my exploration of what Azure can offer on its own as well as a companion technology for SharePoint.

For this endeavor, I’m trying to accomplish all (or at least most of) the following:

  • Implement a WebAPI project using Visual Studio 2013 and implement some basic functionality
  • Deploy the WebAPI project to Azure
  • Consume the WebAPI from a variety of applications and platforms, including desktop browser, mobile devices, and SharePoint Apps.
  • Use OAuth to properly identify and authenticate users.
  • Back the WebAPI with an Azure database for storage and retrieval of data.
  • Allow the WebAPI to use SharePoint Lists and Libraries as a backing store.

In the end, what we’re really trying to achieve here: intergalactic reuse. Regardless of OS, browser, programming language, or platform, we want to demonstrate that functionality can be written once and shared widely in a connected world.

Building the WebAPI Project

If you’re not familiar with the WebAPI project template you might want to take a moment and read this article. While the sample we’ll be building will initially be very similar to the one in this article, over time we’ll be extending it to greater functionality.

1. In Visual Studio 2013 click the New Project link or menu, and then click the ASP .NET Web Application template. Name the project ContactsProject and then click OK.

2. In the New ASP.NET Project Window select the Empty template, confirm that the Web API core reference is selected, and then click OK.

3. Now, we’ll create a Model to represent a Contact. In the Solution Explorer, right-click the Models folder, select Add, and then choose Add Class.

4. Name the class Contact and then click Add.

5. For this example, we’re not trying to implement The Greatest Contact Application Ever – we’re just trying to implement some basic functionality. To that end, add members to your Contact class as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace ContactsProject.Models
  public class Contact
    public int ID { get; set; }
    public string Name { get; set; }
    public string Phone { get; set; }
    public string EMail { get; set; }

6. Next, we’ll add a Controller… to do so, right-click the Controllers folder, click Add, and then click Controller.

7. In the Add Scaffold window select the Web API 2 Controller – Empty option, and then click Add. Name the controller ContactsController and then click OK.

8. Make the necessary changes to the controller code so that it resembles the code below. Note that for now, we’re holding sample data in an array. Obviously, we’ll want to put that in a more appropriate data store at some point.

using ContactsProject.Models;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;

namespace ContactsProject.Controllers
  public class ContactsController : ApiController
    // instance of sample data
    private List _contacts = new List()
      new Contact { ID = 1,
        Name = "Ed Ipus",
        Phone = "404.123.4567",
        EMail = "[email protected]" },
      new Contact { ID = 2,
        Name = "Marsha Larts",
        Phone = "770.123.4567",
        EMail = "[email protected]" }

    public IEnumerable GetAllContacts()
      return _contacts;

If you’re like me, the longer you go without building your code, the less likely it is to build properly, so go ahead and take a moment to build your code and get rid of any syntax errors. Don’t run it, just build it.

OK, now that we have buildable code, we need to implement a simple UI so that we can display the data.

9. In the Solution Explorer… right-click the project (not the solution), click Add, and then click HTML Page.

10. Name the new page index.html, and then click OK.

11. Implement index.html as shown in the listing below. Note that we’re just going for a simple display of the data at this point.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<h2>All Contacts</h2>
<ul id="contacts" /></div>
<!-- jquery source - use the CDN of your choice, or load from your web server if you prefer -->
    <script type="text/javascript" src="http://code.jquery.com/jquery-2.0.3.min.js"></script>
    <script type="text/javascript">
        var uri = 'api/contacts';
        $(document).ready(function () {
            // Send an AJAX request
                .done(function (data) {
                .fail(function (jqXHR, textStatus, err) {
                    alert(‘Error: ‘ + err);
        function showContacts(data) {
            $.each(data, function (key, item) {
                // Add a list item for each contact
                $('<li>’, { text: formatItem(item) }).appendTo($('#contacts'));

        function formatItem(item) {
            return item.Name + ', ' + item.Phone;

12. To test your code press F5. Assuming a clean build and no typos, you should see a page similar to the one below.

Congratulations, you’ve got a functioning WebAPI project and a simple HTML page to display results.

Into the Wild Blue Yonder

So now that we have a functioning WebAPI project, we need to deploy it so that it can be consumed from various platforms and geographies. As I mentioned in the opening of this article, we’ll use Azure for that. To that end, if we’re going to deploy to Azure, then we’re going to need an account. Here are a couple of alternatives:

  • If you or your employer has an MSDN subscription you may have a number of monthly credits to allow you to begin experimenting with Azure. Check the particulars of your MSDN account for further details.

Once you’ve got your Azure account up and running, you’ll need to create a website where we can deploy our application.

1. Navigate to https://manage.windowsazure.com and sign-in with the credentials you used to setup your Azure account.

2. Click the NEW button on the lower left corner of the page.

3. Select WEB SITE, click QUICK CREATE, and then enter a URL for your website (in my case I entered jbucontacts; you’ll need to pick a unique URL that suitable for you).  Specify the appropriate REGION for your geographic location, and then click CREATE WEB SITE.

Excellent! We’ve created a web site! Now, let’s return to Visual Studio and deploy our work.

1. In the Solution Explorer, right-click your project (not the solution) and then choose Publish. Note: during the publishing process you may be prompted to login to Azure again; simply use the credentials for your Azure account just as you did in an earlier step.

2. On the Publish Web page click the Import button.

3. On the Import Publish Settings page… sign-in to Azure if needed, then select the Import from a Windows Azure Web Site option. In the drop-down below the option, select the website you’re deploying to (in my case, jbucontacts).  Once you’ve selected the correct website, click OK.

4. On the next step of the Publish Web wizard you will see a summary of deployment information. In due time you’ll want to go back and explore these details. However, for now simply click the Validate Connection button to confirm that everything is correct; once you’ve confirmed the connection, click the Publish button.

In your browser navigate to the URL of your Azure website and you should see the Web API in action.

Congratulations! You’ve built a WebAPI project, deployed it to Azure, and now you’re interacting with that application from your browser.

Where Will We Go From Here?

As I mentioned earlier, there’s a lot to be added to this sample. We probably need a database… we definitely want login security of some sort… and what about SharePoint… and mobile devices? We’ll get to those in later articles. For now, just bask in the glow of successfully getting your first WebAPI project going and rest (REST?) in the knowledge that we can reuse this code from virtually any platform or geographic location that is Internet-connected.

read more
John UnderwoodWeb API, Azure, and Intergalactic Reuse

Dr. Scriptlove: SharePoint and JavaScript

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.


It’s not because…

I’m an old curmudgeon that resists new things; after all, I do consulting and teaching, and staying up on the latest technologies is an important and enjoyable part of my professional life.

It’s not because…

I’m a zealot for a particular language; I think most modern languages have pros and cons.

Really, my dislike boils down to this:

JavaScript feels like a major step backward in the evolution of programming, and I see it as an easy path to brittle, buggy, unmaintainable code.


Well, I recently attended a training class on SharePoint 2013 and the instructor made an excellent case on writing SharePoint Hosted apps (if you’re not familiar with the application hosting models in SharePoint 2013, please reference this article).




But, if I’m going to do that with any sort of professional satisfaction then I want to really feel like I’m writing elegant, beautiful, maintainable code that I can be proud of.

If you find yourself in a similar circumstance, then let me recommend a three-step process to get you jump-started.

  1. Read this book. More than any other text I’ve seen, JavaScript: The Good Parts does a good job of acknowledging my concerns about JavaScript and providing real answers to address them. Beyond that, it’s just a treasure trove of good practices to engage and bad practices to avoid. It opened my eyes to some of the expressiveness of the language, and while I’m not sure I can call it “love” yet, I’ve certainly gotten past my loathing.
  2. Embrace jQuery. Sure, the old-hands at JavaScript know about this already, but if you’re new to the party then don’t bother wondering whether or not you need this: you need it, and doing any kind of browser-based programming without it just seems unthinkable at this point.
  3. Don’t abandon your architectural roots. Those of us that are schooled in programming know that certain patterns work on building scalability, reusability, and maintainability into our code. Your multi-tiered, loosely-coupled, MVC, MVVM learning still apply here. (By the way, Knockout is an excellent way to implement some of these patterns). It just may take a little more effort on your part to stay architecturally sound since the language and the tooling makes it easy to pollute your architecture.


Go forth and write some elegant code!


read more
John UnderwoodDr. Scriptlove: SharePoint and JavaScript

Top 5 Things Learned @ SPC12

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.

I was fortunate to get to attend this year’s SharePoint conference in Las Vegas.  I saw some great presentations (and one or two that weren’t so great), but overall it was a useful event. It is an exciting time to be a SharePoint developer, and as someone in that role as well as an educational role I thought it would be useful to bring the top 5 things I learned at the event. So, here we go…

Number 5: InfoPath may not be dead, but it’s future doesn’t look very bright

When someone begins a talk with “fully supported” and “protects your investment”, you have to believe that they are talking about a product that doesn’t have much of a future. So it seems with InfoPath. There was exactly one paragraph in one presentation about InfoPath for the entire SPC 2013 event. So what’s the takeaway?

On the positive side, InfoPath 2013 is a new tool that includes a couple of nice features, including much improved integration with Visual Studio 2012.

On the negative side, the lack of InfoPath material at the event speaks volumes about its lack of importance for the future. InfoPath is a farm-only proposition; if you’re doing SharePoint in the cloud, or want to be cloud-compliant for the future, you will have to pursue other options. So what will your other forms-authoring options be?

  1. Build a SharePoint App using Visual Studio 2012 (more about that later)
  2. Build a SharePoint App using Access 2013 (are you kidding me?!?!?!?)

Now, for those of you that just got a little nauseous when I said “Access”, a little clarification is in order. Access is no longer a file-based DB tool; there are no more .MDB files. Instead, Access 2013 is now the forms designer tool of choice. Access stores and retrieves data from Azure DB or SQL Server.  Access 2013 forms are HTML-5 based (I even saw one run on an iPad!). So what’s the SharePoint connection? Access 2013 Forms can be packaged and deployed as SharePoint Apps. So, in a manner of speaking, all of your cloud-compliant options involve “apps”, it’s just a matter of what tool you’ll use and where you’ll store your data.

Number 4: “Themes” may finally be a legitimate branding tool

Let’s face it… the history of “themes” on SharePoint is not a great one. There have been several formats and engines along the way; the tooling was pretty weak; and, most of all, the results were just amateurish. SharePoint 2010’s theming options were particularly disappointing.

SharePoint 2013 brings a new theming engine and new options for building your own themes. Theme information is provided using XML files, and the results shown in the demonstration session at the SharePoint conference were pretty impressive. I consider themes to now fall under the heading of “branding light” – they may be suitable to get the job done in a case where one lacks the skill (or the will) to undertake the changing of a master page of other more invasive forms of branding.

One last thought – the team responsible for themes will be providing some tooling as time passes.  They demonstrated a pre-release tool named “Theme Slots” and promised a release in the near future.

Number 3: You kids get off my server!

Most servers like SharePoint have an extensibility model that will allow developers to extend and customize the product to meet the needs of a company. While this is a compelling option, it has two big downfalls:

  1. Bad code = bad server performance
  2. Upgrades are rarely smooth

So, how does SharePoint 2013 solve this dilemma? By kicking us all off the server (so to speak). Going forward, it will be very rare for us developers to write farm solutions using the server object model. Instead, we will write SharePoint Apps using Visual Studio 2013. These apps will contain code that that runs in the browser or in another server process and employ the client object model to communicate with SharePoint. The good news on this approach is that the server is less vulnerable to errant or malicious code, and that the path to upgrading to the next version of SharePoint is less encumbered. The bad news: it’s going to be a pretty epic shift in how we write custom SharePoint code. We’ll be using the client object model with JavaScript and C#, and we’ll also be using the SharePoint REST APIs. All of this leads to my next point:

Number 2: If you hate JavaScript you’re gonna have to get over it!

For the record, I could go on a long rant on why I hate JavaScript.  I could enumerate all of its shortcomings, and tell you why it’s not a real programming language. But, the reality is, we find ourselves in a world where its shortcomings are outweighed by its benefits. Ironically, JavaScript may actually come closer to the “write once run anywhere” mantra than Java did; or, if you prefer, JavaScript has become the universal client language that calls out to whatever server platform and language that you prefer or need.

So, if you’re going down this JavaScript road for the first time, here are some things that might ease the journey:

  • Embrace jQuery – it is the way to manipulate the HTML DOM.
  • Educate yourself on other useful JavaScript libraries (Knockout is an interesting one that I saw in action this week).
  • Investigate TypeScript – while it still has some rough edges, it may lessen your hatred if you come from the strongly-typed-compiled-language camp.

And finally…

Number 1: A quote to live by…

One presenter from the Netherlands used an interesting phrase when describing the fact that all his demos were live and legitimate:

“There is no bogus here.”

Time will tell if that’s true of SharePoint 2013.

read more
John UnderwoodTop 5 Things Learned @ SPC12