SP2013 host web apps: provisioning fields and content types

Continuing my little diversion into SharePoint “host web apps” or “Full Control apps” (i.e. apps which provision to the host web) within my larger series about apps, today I want to look at provisioning fields (site columns) and content types – but provisioning them into the host web, rather than the app web. Just to explain where we are in my overall series, here’s the evolving table of contents:

1. SharePoint 2013 apps – architecture, capability and UX considerations
2. Getting started – creating lists, content types, fields etc. within a SharePoint app (provisioning)
3. Working with data in the app web, and why you should
4. Access end-user data (in the host web) from a SharePoint 2013 app
5. Rolling out SharePoint 2013 apps to the enterprise - tenant scope and PowerShell installs
6. Azure is the new SharePoint ‘_layouts’ directory
7. “Host web apps” – provisioning files (e.g. master pages) to the host web
8. “Host web apps” – provisioning fields and content types [this article]
9. Deploying SP2013 provider-hosted apps/Remote Event Receivers to Azure Websites (for Office 365 apps)
10. Working with web parts within a SharePoint app

The idea of provisioning fields and content types to the host web are important techniques for host web apps - since if we can have an app which creates fields/content types AND can provision files to the host web (using the techniques in my previous article), then we could use an app to deliver the building blocks for typical SharePoint collaboration solutions.

As ever, this will only be possible if:

• The app requests (and is granted) “Full Control” permission of the host web
  • Note this means it cannot be sold via the Office/SharePoint Store (see Validation checklist for apps for Office and SharePoint). But it can be deployed internally through the organization’s App Catalog..
• CSOM code is used for provisioning, rather than standard Feature XML

N.B. At this point, you might be interested in the “Should you do this? Deciding between host web apps/sandbox/farm..” section of the previous article.

Challenges when provisioning fields and content types to the host web

I think if we’re going to build apps like this, then we’d probably want some helper methods which can:

• Provision fields (as site columns)
• Provision content types
• Add fields to content types

As before, I’m using JSOM code in the default page of my SharePoint-hosted app – this could be adapted to something different if required. Some challenges I noticed were:

• It doesn’t seem possible to be able to create a content type with a specific content type ID with CSOM – perhaps I overlooked something, but in any case it does seem possible to obtain it with a later call
• It seems you have to re-fetch any fields and content types after initial provisioning in order to use them – you cannot use the objects returned from CSOM/JSOM methods. If you try this, it seems CSOM gives you cut-down objects which don’t have some members, and this causes errors like this:
  
  

How to: provision fields and content types to the host web

The code below is a little bit spaghetti-fied, due to it needing a chain of CSOM commands – an improvement would be to move the code over to using promises and jQuery’s deferred object. As it is, some of our methods need to be called in success callbacks since, for example, before we can add the field to the content type we need both to exist.

It also took me a while to realize that I needed a reference to the actual SP.Field to be able to use SP.FieldLinkCreationInformation, and that whilst I could probably obtain my content type’s ID after creation and then fetch it using this ID, simply iterating all the content types and finding mine resulted in the same number of CSOM calls. Anyway, here’s the code I used:

** N.B. My newer code samples do not show in RSS Readers - click here for full article **

Running the app

Once our app is built and we add it to a site, the person adding has to accept the Full Control permission request:

..and just like last time, my app has some sample UI which confirms the steps which have been taken:

 

The result

Now when we go back to the host web, we see that our field and content type have indeed been provisioned:

..and the field has been added to the content type, so it is ready to use:

Download the code

You can download the full Visual Studio project with the code I used for these two articles from here – download the code.

Speaking at SharePoint Saturday Netherlands, June 29th

Just a quick post to mention that I’m looking forward to speaking at SharePoint Saturday Netherlands next weekend. It’s always a privilege to be asked to speak at these things, and the event looks great with fellow speakers including Spence Harbar, Waldek Mastykarz, Wes Hackett, Wouter van Vugt and a whole host of other talented Dutch SharePoint folks.

My session is:

Using JavaScript templates to customise the SharePoint 2013 user interface

Developers often have a need to amend the HTML rendering of SharePoint, especially around lists and list forms, but in previous versions of SharePoint this was not always easy. Many developers resorted to using JavaScript to manipulate the page after it had loaded, even though this was potentially unreliable and unsupported. SharePoint 2013 solves this problem by providing the ability to specify a JavaScript 'display template' for several user interface elements. This session examines key developer scenarios, such as implementing custom rendering for SharePoint lists (including conditional formatting), customizing the display of the Content Search web part and providing an enhanced search 'hover panel' for specific items. Come and learn how to transform the SharePoint interface the supported way!

Look forward to seeing folks there!