Quantcast
Channel: Vardhaman Deshpande
Viewing all 134 articles
Browse latest View live

JSOM Provisioning: Creating SharePoint artifacts without declarative XML

$
0
0
The recent guidance from Microsoft regarding the provisioning of SharePoint artifacts is pretty clear. The recommendation is to completely move away from declarative creation of Site Columns, Content Types etc. and instead, create them completely from code.

To support this approach of programmatically creating artifacts, a lot of work is being done on the "Provisioning Engine" in the OfficeDev Patterns and Practices Library on GitHub. To put it very simply, the Provisioning Engine reads a predefined XML file called the "PnP Provisioning Schema" and creates all the SharePoint artifacts using CSOM. Since this engine predominantly uses C#/.NET, it is expected to be run from somewhere like an Azure Web Job, a Web Application on an IIS server or a simple console application.

This method of provisioning is great for clients who opt for Azure subscriptions or IIS servers along with their SharePoint roll-outs. But this is not necessarily true with clients who only want to go for SharePoint or who do not have enough budget for additional Azure or IIS installs. So far, the only option in these cases is to go with the traditional declarative XML based provisioning using No Code Sandbox Solutions (NCSS). This approach is still valid at this time and Microsoft has stated that No Code Sandbox Solutions continue to remain supported:
http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx

Still, in this post I am going to explore another form of provisioning SharePoint artifacts completely based on the JavaScript Object Model (JSOM). Since the provisioning is done completely from JavaScript running in the browser, there is no need for a platform like Azure or IIS to run this code. I came across the following project in Office Dev PnP which shows how to use a SharePoint hosted Add-In (App) to create artifacts like Site Columns and Content Types etc. in the host web.

https://github.com/OfficeDev/PnP/tree/master/Samples/Provisioning.Jsom

Some code examples from the project:

1) Create Site Column:




2) Create Content Type:




Here are my observations about this approach:


1) This project uses a SharePoint Hosted Add-In (App) to run the JSOM code. But with a few modifications, it can be made to run from a JavaScript file provisioned to a document library with a No Code Sandbox solution. The readme file of this solution mentions an additional project "Provisioning.Jsom.Ncss" which seems to be missing from the solution. My guess is this project did the exact same thing. With this approach, we remove the dependency on the Add-In (App) Model for provisioning.

2) Currently for values like site column names, types, content type names etc hard coded strings are being used. This can be modified to be read from an XML file, preferably the PnP Provisioning Schema. The schema XML file can be deployed with the Provisioning JavaScript file in the NCSS itself.

3) This approach can be used to create sub sites but not site collections as there is no way right now to create site collections through JSOM. So the deployment process will have to be manual creation of a Site Collection with an empty web template, and then to upload the WSP which will deploy the JS file to the SharePoint site. This file will then do the artifact provisioning.

I am going to explore these options and will post something in the future around this approach.

Thanks for reading. Hope you find this information useful in some way!


Modify Regional and Language settings with JSOM and JavaScript

$
0
0
Recently, the ability to modify the Regional and Language settings of a site has been added to the client APIs in SharePoint 2013 and SharePoint Online. While the support for SharePoint 2013 was added in the December 2014 CU (as announced by Vesa here), the support for SharePoint Online has been a more recent addition.

There are some really nice code examples for the CSOM Regional and Language APIs in the Office Dev PnP Library:
https://github.com/OfficeDev/PnP/tree/master/Samples/Core.Settings.LocaleAndLanguage

But, I could not find JSOM code example of these APIs. So I am listing down some of the most frequently used Regional and Language functions here.

1) Add a Supported UI Language:



2) Remove a Supported UI Language:


3) Disable Multi Lingual and Remove all UI Languages:



4) Get Regional Settings:


A full list of all the regional settings properties is available here:
https://msdn.microsoft.com/EN-US/library/office/jj244880.aspx



5) Set Regional Settings:




6) Set Time Zone of a site:


This one was a bit tricky but I finally got there in the end. You will need to know the ID of the Time Zone you want to set in the site. A full list of SharePoint TimeZone IDs is here:
https://msdn.microsoft.com/library/microsoft.sharepoint.spregionalsettings.timezones.aspx



Hope this helps!

Avoid customizing the SharePoint Online root site collection

$
0
0
I had an interesting decision to make recently: Should the root site collection of the SharePoint Online tenant be used to host the main intranet landing site? A very common requirement for a SharePoint Online project is a customized landing site with the company's branding, logo and some custom functionality. You might refer to this as the Home page, Intranet home, Portal site, News hub etc. It's a site where the users will first land when they arrive on the Intranet/Digital Workspace.

So where should this site be located? Right now, I would NOT recommend this to be the root site collection in SharePoint Online (https://tenant.sharepoint.com) It is much more convenient to use another site collection like /sites/intranet or /sites/portal etc. In fact, I would recommend that the root site collection should be left alone and no customizations should be deployed to it. Here are the reasons why:


1) Custom Scripts


In the SharePoint Online admin portal, you can assign a site collection under which the self-service sites will be created. (by default it is the root site collection of the tenant e.g. https://tenant.sharepoint.com) So whenever a user creates a self-service site, it will be created as a sub site of this site collection.

SharePoint Online also gives you the ability to turn off custom scripts on self-service created sites. (The default is that custom scripts are NOT allowed on self service sites). This is to prevent users from injecting scripts into web parts and compromising the integrity of the site. This article describes this feature in detail:

But what the article does not mention is that the custom scripts are disabled only on the site collection (and its sub sites) which is assigned for creating self service sites. All other site collections in the tenant can still run custom scripts.  I have highlighted the relevant areas in the image below:


(click to zoom)



Now just to recap, here are the defaults when you create a new Office 365 tenant:

1) Root Site collection is assigned for creating self service sites.
2) Custom Scripts are turned OFF for the site collection under which the self service sites will be created. 

Naturally, your customized intranet portal will have lots of JSOM or REST API/Ajax code embedded in Script Editor or Content Editor Web Parts. If this custom site is to be located at the root site collection, you will have to change at least one of these default settings. Either nominate a different site collection for creating the self service sites or change the Custom Scripts option to "Allow users to run custom script on self-service created sites"

Depending on how strict the governance is, changing default settings can be easy in some cases but more often that not, you will have to have a valid reason if you are going to do this in production tenants. 

2) Root Site collection cannot be created using PowerShell Cmdlets


There is a limitation in the SPO PowerShell Cmdlets which prevents you from creating the root Site collection. When you try doing so, you get the following error:



Now in most projects I have worked on, we have had a deployment script which runs off the build server. For integration testing, the deployment script creates a new site collection once every day and deploys the latest code to it. If you have a similar continuous integration process, you will not be able to create a new root site collection with the deployment script. It will have to be a manual step each time the deployment is done. This can get bit annoying.

3) No flexibility to delete and re-create the Site collection as everything else stops working. 


If something goes wrong in the deployment or some site columns or content types are corrupted, I do like to have the flexibility to delete the site collection and start afresh by creating a new one with the same url.  This is not really an option if you are deploying to the root site collection.

If you delete the root site collection, all other site collections in the tenant will stop working. I have also observed that SharePoint Search also stops working. This is why when you try to delete the root site collection from the admin portal, you get a big red warning message:

(click to zoom)

Now if this is a developer tenant and multiple developers are working in their own site collections, they will be blocked until a new site collection is created at the root.

If this is a production tenant and something else like the collaboration solution is already deployed to another site collection in the tenant, it will also stop working.  

The reason for this seems to be that when a user wants to navigate to any site collection in the tenant, the authentication is done via a page located in the root site. If the root site collection is missing, the user cannot be authenticated and hence cannot navigate to any site collection.

(click to zoom)


Due to all these reasons, I feel that the root site collection is an important piece for SharePoint Online to work correctly. I recommend treating it as you would treat a configuration site. It is best to leave it alone and not deploy any customizations to it.

Hope you find this article helpful!

Update user language and regional settings with CSOM

$
0
0
Following my previous post around multilingual aspects of SharePoint Online: Modify Site Regional and Language settings with JSOM and JavaScript

Here is a bunch of CSOM code which will update the personal regional settings of the current user or another user (if you are a tenant admin and have the rights to update user profiles):

Before update:




The code:



After update:



Thanks!


Install and Update Sandbox Solutions with CSOM

$
0
0
So recently, I was working on a SharePoint Online project and was looking for a way to automate the installation and update of a No Code Sandbox Solution (NCSS).

I was aware that you can install and activate Sandbox solutions in SPO with the following CSOM method:
Microsoft.SharePoint.Client.Publishing.DesignPackage.Install

There are a number of articles already covering this:

http://blog.symprogress.com/2013/07/apply-designpackage-using-client-object-model/

http://blogs.msdn.com/b/frank_marasco/archive/2014/08/10/upload-and-activate-sandbox-solutions-using-csom.aspx

The Office Dev Patterns and Practices project also uses this method to install a solution:
https://github.com/OfficeDev/PnP-Sites-Core/blob/master/Core/OfficeDevPnP.Core/AppModelExtensions/WebExtensions.cs

Just so you know, there are a couple of caveats to this approach as mentioned in the PnP documentation:
// NOTE: The lines below (in OfficeDev PnP) wipe/clear all items in the composed looks aka design catalog (_catalogs/design, list template 124).
Also, installing and activating the solution with this method will also automatically activate all Site-Collection level features, even if they have been set to AutoActivate = False


What I have found is, by changing the Major and Minor version numbers (which renames the WSP), you can also use the same method to update an existing solution

Here is my PowerShell script which Installs a solution (if it does not already exist) or updates it if the solution already exists, and the Major or Minor version number is different.

The PowerShell script:


The script is straightforward and similar to the other posts. The main difference from the PnP version being I do not run the DesignPackage.Uninstall method before Installing the solution and I also run the DesignPackage.Applymethod after Installing the solution


1) Install a Solution:



After the script is run, I can see my WSP installed in the solution gallery with the Major and Minor versions I specified:

2) Update a Solution:


To update the solution, first we will need an updated WSP. It should have the relevant sections specified in the UpgradeActions Feature XML element.
@cann0nf0dder has a great post on configuring a sandbox solution for update here: Upgrading Sandbox Solutions in SharePoint

Once you have the updated WSP, all you need to do is change the Major and Minor version numbers in the script and Install your new WSP.


After the script is run, I can see my WSP is updated to the new version in the solution gallery with the Major and Minor versions I specified:


This way, the same DesignPackage.Install and DesignPackage.Apply methods can be used for updating sandbox solutions in SharePoint Online. 


Custom multilingual text in SharePoint Online using Taxonomy and JSOM

$
0
0
I have been working on an Office 365 global intranet which will be rolled out to about 55,000 users worldwide. Naturally, one of the core requirements of the solution is that it should be multilingual. In my previous posts on this topic, Modify Site Regional and Language settings with JSOM and JavaScript, we had a look at how to set alternate languages for a site and in Update user language and regional settings with CSOM, we saw how to set the preferred display languages for a user.

This allows a user to see the SharePoint site chrome in their own preferred language. Now in this post, lets have a look at how to have localized custom text so that the user can see custom labels, headings etc. in their preferred language.

Some notes around this:

1) This approach is based on the multilingual features of SharePoint Term Sets:


It is possible to have multi-lingual term sets because each term in a term set has a unique ID and each term can have multiple labels. You can designate a default label for a term in each language available for a term store. A term can then have multiple synonyms in each of these languages, as well as labels and synonyms in other languages.

Users will also see managed terms displayed in their preferred language, regardless of the actual default language of the term store.

If no labels are specified for terms in the language in which a user is viewing a term, then the default label for the term in the default language of the term store will be displayed to users.

https://support.office.com/en-us/article/Work-with-multi-lingual-term-sets-D04098AF-282B-45C3-97CB-59363042C1B3

3) Based completely on JSOM, JavaScript and the SharePoint Term Store.


4) This approach is built on top of the MUI features in SharePoint. Which means that the user created content such as list item data, documents etc. will NOT be translated.


5) The SharePoint Online Term Store is treated as a "data source" for custom multilingual text. Each custom text is a term in the "Translations" term set. For each language that you have to support add a new label to the term for that language.


Lets get started:

1) Setup the Term Store to support term labels in multiple languages


I have set the default language of the Term Store as English and then added Dutch as a Working Language. This means that the term store will be able to support labels for a term in English as well as Dutch.



After adding the working languages, I have created a new Term Group called "My Group".
Under "My Group", I have created a Term Set called "Translations".
Under "Translations", I have created 3 terms: Communications, Marketing and News.
We will use these 3 terms to show the custom multilingual text.

We need to add the default language labels for each term:



After a label has been specified for each term, they will appear in the following way:

When English (default) is selected:



When Dutch is selected:



The translation framework will work in the following way:

If I am an English user and I have set my preferred language as English, when the terms for the "Translations" term set will be returned,  JSOM will return the English language labels by default. 

If I am a Dutch user and I have set my preferred language as Dutch, when the terms for the "Translations" term set will be returned,  JSOM will return the Dutch language labels by default. 

If I am an Italian user and have set Italian as my preferred language in my user profile,  SharePoint will return the English labels for the Translations term set as we have not selected Italian as one of the Working Languages of the Term store, nor have we set any labels in Italian.



2) Add Local Custom Properties to Terms


Next, we will add a local custom property for each term to identify it regardless of the language. This will serve as the ID of the term when we fetch it from JSOM:



This is the list of the local custom properties I have created for my terms:

Term
Local Property Name
Value
Communications
TranslationID
MUITextCommunication
Marketing
TranslationID
MUITextMarketing
News
TranslationID
MUITextNews

We could use the Term GUID here but I prefer using a custom ID as it is more readable. Also, if someone deletes one of the terms by mistake, it is easy to create a new Term and set the custom ID in the properties. If we were using a GUID, we would have to use code to create a new term with a specific GUID.

3) The Translation framework


After the Term Store is correctly setup, all we need to do is get the terms from the "Translations" term using the JavaScript Client Object Model (JSOM) and display them in the UI:
  • Query the term store to get the terms from the "Translations" term set.
  • SharePoint will return the term labels in the current user's preferred language if:
    • The alternate language is enabled on the current site
    • The current user has set the language as a preferred language in their user profile
    • The term store supports the language as a "Working Language" as shown in step 1
    • A default label is defined for the terms in that language.
  • If any one of these conditions is not fulfilled, then the English labels for the terms will be fetched as it is the default language of the Term Store. 
  • The term labels will be stored in the cache.



4) Performance/Caching


Since it is not advisable to make a call to the Term Store on every page load, it is a good idea to cache the labels for a particular user. My recommendation would be to use the browser web storage. Whether you use session storage or local storage depends on the implementation of the solution. MDN has a great article on this https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

For demo purposes, I am using the sessionStorage and storing the term labels as a JSON object.

When the preferred language of the current user is English:


When the preferred language of the current user is Dutch:


5) Using the framework to show localized text


After the framework is correctly setup, all we need to do is call the framework correctly to show the custom text in the language of the current user:



When this code runs, if the preferred language of the current user is English, they will see the English text:




If the preferred language of the current user is Dutch, they will see the custom text in Dutch:


This way, you can utilize the multilingual features of the SharePoint Taxonomy Term Store to show multilingual custom text in your solution.

Using Office 365 Connectors for Groups in ASP.NET MVC

$
0
0
At Connect(); 2015, a new feature for Office 365 Groups called custom connectors was launched. With custom connectors, a new conversation can be started within an Office 365 Group programmatically, from your own custom application.

A very handy guide to custom connectors is available on the Outlook Dev Center: Office 365 Connectors for Groups (Developer Preview)

In this post, lets have a very simple look at how to use a custom connector from your ASP.NET MVC application.

The sample code for this post is available here: https://github.com/vman/Office365GroupsConnector

Before we get started, it is recommended to have SSL configured for your ASP.NET MVC application:
Configuring an ASP.NET project for development with SSL

1) The Connect to Office 365 button:


The way the connect to Office 365 button works is really simple, all it does is to redirect the user to the connectors page for Outlook and then after authentication, redirects the user back to a specified callback page. Here is the html for the button

And the description for each query string parameter from the Outlook Dev Center page:

ParameterDetails
stateYou can use the state parameter to save your application state. If you supply a value for state it is returned back to the specified callback_url when the application returns. This is an optional parameter.
app_nameProvide your application name. This name will show up in the authorization popup and in the connector list page that your users would see. The app_name is a mandatory parameter and can range from 1 to 100 characters.
app_logo_urlProvide the URL to your application logo. Ensure that the link is not behind an authentication wall and is publicly reachable. Use a logo of size under 10KB (preferably 256x256px) and type JPEG, PNG, GIF, TIFF, BPM, X-ICON or SVG+XML. The app_logo_url is a mandatory parameter.
callback_urlThe callback URL should be a valid HTTPS URL without any query parameters. When the application returns successfully, the state passed, name and webhook URL of the selected group are returned as query parameters to the callback_url. If the application encounters a failure the state passed and the error code are returned to the callback_url.

This is how the button is rendered on your custom page:



2) Authentication:


When you click on the button, you are taken to the Office 365 Sign-in page if you are not already signed in. Next, you get a list of Office 365 Groups which you are a member of. You have to select a group in which the message will be posted, and click on Allow:



3) The Code:


The next step is to actually post the Office 365 Group card. Behind the scenes, I have used RestSharp in an MVC controller to make the post:






4) Navigate to the Office 365 Group:


And if you now navigate to the Office 365 Group in Outlook, you will see 2 new messages, the first one is when the connection to the custom application is set:



And the next one is the actual message we posted from the MVC controller:


Thanks for reading!


Known Issues:


Since the custom connectors are in Dev Preview right now, there seem to be few issues which need to be ironed out:
  • For me, the code only worked on Chrome and not on IE. Even then, I would get timeouts during the authentication part.
  • I would also get the following error intermittently if I was not already signed in to Outlook. The workaround was to open a another tab and sign in to Outlook which then made the authentication work.



Search a Taxonomy term in a TermSet using JSOM

$
0
0
Here is some code I put together to search a term within a term set. This is for scenarios when you have a large term set and need to efficiently find a term with a specific label.

In this code, I am searching for all terms which start with an "A" in a term set which contains locations from around the world:

Note: I am using JSOM here but this also works with CSOM



Result:



Simple bundle, minify and upload JS to SharePoint using Gulp

$
0
0
I recently started playing around with Gulp and was not really impressed until I came across the gulp-spsave plugin. This plugin will let you upload your JS/CSS files directly to SharePoint right from Visual Studio 2015! This meant that I no longer had to manually upload my JS files to SharePoint or use SharePoint Designer to edit my JS/CSS files!

This got me more interested in Gulp and I started exploring how can I further improve my debugging and build workflow with Gulp. After spending some more time, I came up with a basic workflow which will definitely get you interested in Gulp as a SharePoint/Office 365 Developer!

This is a simple workflow which will look for predefined JavaScript files in your Visual Studio 2015 project. If any of your files change, it will be bundled into a single JavaScript file, minified and uploaded to SharePoint.

Here is my project on GitHub: https://github.com/vman/SP-Simple-Gulp-Demo

The plugins used in this demo are:

gulp-concat : Used to bundle js files.

gulp-uglify : Used to minify the js files

gulp-rename : Used to rename the minified file to .min.js

gulp-spsave : Used to upload files to SharePoint

Here is the file structure of my Visual Studio 2015 project. It is a simple ASP.NET project where I have removed all unnecessary files. Since this is a strictly front-end/UI project, you could also open a folder in Visual Studio as described in this StackOverflow post.


The Scripts folder contains the JS files I will be working on. For demo purposes, I have copied the files from the Core.JavaScriptCustomization project in PnP.

The Output folder is where my output files GulpDemo.js and GulpDemo.min.js will be created. These will also be uploaded to SharePoint.

The GulpFile.js is where all my Gulp tasks will be defined. 

The package.json file is where all the NPM packages required for my tasks will be defined. 

So without further ado, here is the code for my Gulp tasks:


After creating your gulp tasks, you can run them from the Task Runner Explorer window in Visual Studio 2015:


After changing the scenario1.js file, I can see that the concat, minify and upload to sp tasks are triggered as well:


Thanks for reading!

Minify custom SharePoint themable CSS with Gulp

$
0
0
The ability to create your own themable CSS has been present in SharePoint for a long time:

How to: Make custom CSS files themable in SharePoint 2013

Working with the SharePoint Theming Engine

You can even define custom names/properties in your .spcolor files which can be used in your custom CSS. My colleague Matt Holden has a great post on this here:

Custom .spcolor files for SharePoint Composed Looks

We were using this method in one of our SharePoint Online projects along with Gulp tasks to bundle and minify all our JavaScript/CSS files as per my previous post Simple bundle, minify and upload JS to SharePoint using Gulp

Now, the SharePoint theming engine uses CSS comments to determine the color replacement:

As per Matt's post, the theming engine replaces the values at run-time to the color defined in the ContentAccess1 section in the spcolor file.

For the theming engine to successfully carry out this replacement, the ReplaceColor comment needs to be present in the CSS file we load in SharePoint.

When I minified the Themable.css file using the clean-css gulp plugin, it stripped out all the comments which made the replacement not work:

Then I noticed that the clean-css plugin provides an option to keepSpecialComments when it does the minification. I tired using that but it still did not work as special comments have to start with an exclamation mark: https://github.com/jakubpawlowicz/clean-css#how-to-preserve-a-comment-block

Adding an exclamation mark before the comment was not going to work as that would be invalid syntax for the SharePoint theming engine.

So my final solution was to convert the ReplaceColor comment to a special comment before processing it through the minifier, then letting the minifier do it's thing by minifying the css file but preserving the special comments, and then after the minification, again converting the special comment to a regular comment suitable for the SharePoint theming engine:

Which then gave me the minified CSS along with the required comments preserved:

Thanks for reading!

Add TermStore Managers and Contributors using CSOM

Identify Office 365 Tenants using a custom logo

$
0
0
I came across something really simple but equally useful recently.

It is quite well known that Office 365 allows you to set a custom image as a logo for your organisation. This logo then appears in the suite bar across the entire tenant.

When working on an Office 365 Development project, we have multiple tenants to take care of. Typically, they are  DEV, TEST, UAT and finally PROD.

When you are navigating between these tenants, a really simple way of telling them apart is to use a custom logo for each tenant!

We as developers might just quickly have a look at the URL to see which tenant we are in. But in many cases, the same tenants are used by non-technical members of the team who might need a clearer indication of which tenant they are in. This can also help in preventing someone accidentally doing something on the wrong tenant.

So here at Content and Code, we might have something like this:

Development Tenant:



Test Tenant:



UAT Tenant:



PROD does not require any special logo as that might confuse end users:



Here is how you set the custom theme and logo for your tenant:

https://support.office.com/en-us/article/Customize-the-Office-365-theme-for-your-organization-8275da91-7a48-4591-94ab-3123a3f79530

Hope you find this useful!

SharePoint Online: Get UserProfile Properties with REST API Batching

$
0
0
In my previous post SharePoint 2013: Get UserProfile Properties with REST APIwe saw how to fetch SharePoint UserProfile properties with the REST API.

The only thing missing in that post was, at the time there was no way to get Multiple UserProfile Properties for a Specific User i.e. if you had an account name of a user and wanted to fetch multiple custom or default UserProfile properties, you could not do that in a single REST call. You would have to resort to either making multiple REST calls using the GetUserProfilePropertyFor function, or you would have to use the JavaScript Client Object Model (JSOM)

When I wrote that post, SharePoint Online did not support REST API batching. Since then, it has been implemented and as a result we can get multiple Custom/OOB User Profile properties in a single REST call.

Here is my code showing how to do it:

Here are some other great resources on SharePoint REST API Batching:

Batch Processing (OData Version 3.0)

Part 1 - SharePoint REST API Batching - Understanding Batching Requests

Make batch requests with the REST APIs

Thanks for reading!

SharePoint Online: Write User Profile Properties with REST API

$
0
0
In my previous posts, we saw how to Set user profile properties using JSOM & JavaScript and Set another user's profile properties with CSOM

Now, here are some code snippets I have put together to set SharePoint User Profile properties with the SharePoint REST API

  • This code only works with SharePoint Online at this time.
  • Can be used to set single value as well as multi value user profile properties.
  • Can be used to set default (OOB) as well as custom user profile properties.


1) Set Single Value User Profile property with REST API:



2) Set Mutli Value User Profile property with REST API:


Hope you find this useful!

Getting started with TypeScript, Browserify and Gulp in SharePoint

$
0
0
In my previous post Simple bundle, minify and upload JS to SharePoint using Gulp we saw how Gulp tasks can be used to simplify our JavaScript development experience in SharePoint. I am really impressed with Gulp as it has increased my productivity and I don't remember the last time I used SharePoint Designer :)

Now let's see how can we bring TypeScript into the mix. I have been playing around with TypeScript for a while now and here is my basic development workflow:

1) Create a main app.ts file which will contain the primary code for my application or "WebPart". In addition, app.ts will also have import references to any custom or third party modules e.g. jQuery

3) Use tslint to check the quality of my TypeScript

4) Use browserify and tsify to parse my TypeScript file and create a single JavaScript file (app.js) which includes all the dependencies required to run my app.

5) Minify my app.js using gulp-uglify and rename it to app.min.js using gulp-rename

6) Upload the debug and minified files to the Style Library in SharePoint using gulp-spsave

7) Then the JavaScript files can be used any way I like e.g. embed it using a Custom Action or in a Script Editor or a Content Editor WebPart.

Before we begin, if you are using Visual Studio 2015 like me, make sure you have the latest version of Node installed and Visual Studio is configured to use it. Here is an excellent tutorial on how to do this: How to configure Visual Studio 2015 with the latest version of Node.js and NPM

Now let us have a look at the important bits of my solution. I have uploaded the entire solution on GitHub here: https://github.com/vman/MyTypeScript

1) app.ts file:


At the top, the import statements are used to indicate that the code in this file is dependent on these modules. The first being jQuery and the second being my custom User module. Next, we simply create an object of the User class and call it's getDetails and displayDetails methods.

2) User.ts


There is a bit more going on in my User.ts class. Just like my app.ts, the first line indicates, with an import statement, that this file is dependent on the jQuery module. The getDetails function gets the AccountName, DisplayName and Email of the current user from the SharePoint REST API and stores them as properties of the current instance. The  displayDetails function logs the same properties (of the current instance) to the console.

3) package.json


Here is a list of all npm packages used in my solution. Notice the jQuery package, browserify and tsify use it to include jQuery in the final bundle as it is requested by my app.


4) gulpfile.js


And finally, here is my gulpfile.js which does all the heavy lifting:


5) Gulp tasks:


The watch-ts-upload-to-sp task looks for any changes in the .ts files (app.ts and User.ts). If any changes are noticed, it runs the upload-to-sp task.

The upload-to-sp task has dependencies chained up so that the tasks are run in the following order:

1) lint-ts to check the code quality of TypeScript
2) browserify to import all the required modules and create a single app.js bundle file
3) minify-js to create a minified file.
4) Finally, the upload-to-sp task runs to upload the app.js and app.min.js files to the Style Library.

(click to zoom)


A note on Typings:


TypeScript uses TypeScript definition '.d.ts' files to provide intellisense while writing a file. The TypeScript Definition Manager"Typings" is the current recommended approach of including definition files in your project: https://github.com/typings/typings

I have included typings as an NPM package in my solution (have a look my package.json file) and then used the following commands to get the required typings in my project:

Thanks for reading!

Upload changed display templates to SharePoint using Gulp

$
0
0
Here is a quick tip which might be helpful when working with display templates. A typical SharePoint solution can have a large number of display templates but while working with them, you might me modifying/customizing only one at a time. Here is a quick gulp task I have put together which watches for changes in the HTML file of the display template and uploads only the changed display templates to the Master Page gallery.

Then I just start the watch task and change/save a display template:



Whenever I save an HTML file of my display template, it gets uploaded and checked-in in the Master Page Gallery. That causes a corresponding JS file to get generated automatically so I don't have to worry about managing it. 



If you are maintaining your Display Template JS files in source control, you will have to remember to copy the generated JS file back into your solution. 

Hope this helps you speed up your Display Template development. I have uploaded this project on GitHub here: https://github.com/vman/Gulp.DisplayTemplates

Thanks for reading!



First SPFx webpart: Get/Set a single value userprofile property in SharePoint

$
0
0
So the Developer preview of the SharePoint Framework was released last week and I decided to get my hands dirty right away. This is a webpart I created just to get a hang of things and to learn the key concepts of the SharePoint Framework.

The code is on GitHub: https://github.com/vman/Edit-User-Properties



Since I had not worked with React a lot, I decided to choose it as my JS framework.

Things I managed to wrap my head around while creating this simple webpart:

1) How to create a SPFx webpart with React as the JS framework.

2) How to talk to SharePoint from within the SPFx webpart with context.httpClient.get and context.httpClient.post

4) Creating reactive as well as non reactive webpart properties

5) The new _spClientSidePageContext object which contains heaps of context data. According to the wiki, properties of this object will be deprecated and moved under the Context object of the webpart.
https://github.com/SharePoint/sp-dev-docs/wiki/Drop-1

(For now, I had to manually create an ambient declaration for this object but hopefully soon, the need for this will go away as it will be moved in the Context object)

6) Office UI Fabric and React Components for Office UI fabric


Since lots of these things were new to me, you might find some bugs/mistakes/horrors in the code so apologies for that in advance. Don't forget to leave a comment and I will be happy to update my code.

Thanks!

Making a POST request to SharePoint from an SPFx webpart

$
0
0
Following up on my previous post First SPFx webpart: Get/Set a single value userprofile property in SharePoint, in this post I have separately documented how to make an HTTP POST request from your SPFx webpart. There are lots of posts out already which show you how to make a GET request so I will not cover that here. It is fairly straightforward once you understand all the moving parts.

Some notes around this:

1) The SharePoint Framework (SPFx) is in Developer Preview now so any/all the content of this post is subject to change (although I hope it doesn't)

2) SPFx webparts are not meant for production use at this time.

3) In this sample, I am making a HTTP POST request to SharePoint to create a list.

4) There is a feature/bug in SPFx right now where it adds the odata-version:4 header to every request that does not have the odata header declared. This causes calls to the SharePoint REST API to return malformed responses as it only supports Odata V3 at this time.

So the workaround right now is to explicitly add the odata-version:3 header to every request as shown in the following code.

5) All the code I have shown here is in TypeScript version 1.8.9 as currently dictated by the SharePoint Framework.

Without much further ado, here is the code:

Declare an interface which will be used in the code. This will need to be outside your webpart class.

Now, the code which makes a POST request to create a list:

And my "Developer workbench" list is created:



Hope this helps.

SharePoint Framework: Validating properties in the Web part property pane

$
0
0
Yup, you read it right. Validations can be added to the properties in the web part property pane of an SPFx webpart. The validation function can be Synchronous as well as Asynchronous. 

This means that we can immediately determine whether a property is valid or we can make an HTTP request (e.g. to SharePoint) and then determine if a property is valid depending on the response.

In the following code, I have added a validation to the title property to make sure that it is not the same as the SharePoint site title. Also, I have added a validation to the description property making sure that it is not less than 10 characters. 


The code is pretty straightforward. This code should be placed inside your Web part class:

As you can see from the code, the _validateTitleAsync function fires when the title property is edited. It makes a GET request to SharePoint to get the title of the web:



The code for this post is located here: https://github.com/vman/SPFx-Web-part-property-validator

The complete Web part class with the property pane editor is here:
https://github.com/vman/SPFx-Web-part-property-validator/blob/master/src/webparts/propValidator/PropValidatorWebPart.ts

While working on this post, I have discovered two possible issues with the way property pane validations currently work in the SharePoint Framework. I have posted them here if you are interested:

1) Rename IPropertyPaneTextFieldProps.onGetErrorMessage to IPropertyPaneTextFieldProps.GetValidationMessage

2) When property pane is in Non-Reactive mode, the validation function should only fire when clicked on "Apply"


Thanks for reading!

Batch REST requests in SPFx using the ODataBatch preview

$
0
0
This is one of my favorite things in the SharePoint Framework right now. The ability to easily batch REST API calls and send them to SharePoint in a single request.

There is a new class called ODataBatch which is used to combine multiple REST requests. You can find more about this in the API docs:
https://sharepoint.github.io/classes/_sp_client_base_.odatabatch.html


As shown in the docs, the ODataBatch class has 2 primary methods: execute and fetch. The fetch method is used to queue all the different requests and execute is used to execute them all at once.

The get and post methods are syntactical sugar to call fetch but with the method parameter set to GET or POST.

The amazing thing about the fetch method is that it returns a Promise object which correlates to the API call being made. This way, when the Promise gets resolved/rejected after the execute method, we can easily track the response. This is better explained in the code below :)

Before we move on to the code, it is important to know that there are couple of bugs with the ODataBatch class right now:

1) The ODataBatch class only works with GET requests for now. If a POST request is added to the batch, it is treated as a GET request and is not wrapped in a changeset. I have added this issue here:

POST request in an ODataBatch request is not wrapped in a changeset

2) The ODataBatch class does not work with the SharePoint Search API at this time. This is because by default an odata-version:4.0 header is added to the batch request with there being no way to override it right now. More details here:

The IODataBatchOptions interface does not extend the RequestInit interface

So let's have a look at how we can utilize the ODataBatch class in an SPFx webpart:

First, we will need to import all the necessary modules:

And here is the actual code:



When this code is executed, we can see that a single batch request is sent to SharePoint containing the information about the requests in the Payload:



And when the Response is returned, we can hook into each individual Promise object to get its value:


Isn't this Awesome? It is going to save a lot of round trips to the server and also help in performance optimization. Hopefully the bugs will be fixed in the next release of the SharePoint Framework and we can utilize the ODataBatch class to it's full potential!

Here is the link to my project on GitHub if you are interested: https://github.com/vman/ODataBatch-Explorer/blob/master/src/webparts/odatabatcher/OdatabatcherWebPart.ts

Thanks for reading!
Viewing all 134 articles
Browse latest View live