Veni, Vidi, Vici

In the first post in this series I discussed some of the benefits of formalizing your client-side development process and then a bit about starting the process of tooling up. A common scenario to develop our own client-side solutions in SharePoint is to point a Content Editor (CEWP) or Script Editor (SEWP) web part at our custom html, css, and js files that are sitting in a document library somewhere in our environment. In this post I want to dive into the most basic implementations of a development toolchain that will automatically deploy those files into a location in SharePoint. This does not mean, and in most cases, should not mean, “production”. What it means is that while you’re developing your code any changes you make will be automatically uploaded to a location that you already have your CEWP or SEWP pointed to, that way when you refresh the page your custom solution will refresh with the latest version of your code. To accomplish this, we’re going to use Gulp which is a JavaScript based task runner similar to the build process that exists in Visual Studio. [Continue Reading]

Last year, around this time, Marc and I agreed we should write a blog series on our development process. As often happens good intentions get buried in other commitments, but I’ve finally managed to circle back on this topic which I’m finding has become more important than ever. Over the last year the SharePoint Framework has taken off. Although it still doesn’t support the paradigm that I most often am developing for - the full-page app hosted in SharePoint - I still think it’s a great model for development. At this point Modern has come far enough in its parity with Classic that Marc and I are recommending to our clients on or going to Office 365 to go Modern first, and then fall back if you’re impeded. That said, we know from our client conversations that a significant number of organizations are still using legacy versions of SharePoint, some all the way back to the 2007 version. There is absolutely nothing wrong with that if it’s working for your organization, but I suspect some people are feeling a little left out in the cold with regard to how they fit into the conversation when SharePoint Framework is at this time only for SharePoint online or for SharePoint 2016 with Feature Pack 1. Further, I suspect many on these older versions envision a time in the not too distant future where they will be migrating to either a newer/newest version of the on premises product or to Office 365. The point that I’m going to make in this series is that even if you’re not using the SharePoint Framework you can create your own process that mimics the toolchain and propels your development from a bit of a hack into a more formalized process. Not only does this help your organization; it helps you become more marketable in today’s SharePoint development environment. [Continue Reading]

A recent comment on my blog post “SharePoint time, is not your time, is not their time.” has prompted me to create a short addendum post that specifically references updates and how your thinking might differ from displaying SharePoint date/time values. To recap our example, I was discussing how to manipulate the date values to have your client-side code mimic (or not) the regional settings of your SharePoint site. The question was raised about how to deal with dates when doing POST to a SharePoint list or library from your client-side code. [Continue Reading]

There will be some that find what I’m about to say entirely obvious. For those that don’t this is a great way to think about development when the terminology changes but really everything stayed the same. Azure Functions are billed as “serverless computing”, and as I’m sure most of you have figured out already, all this really means is that the Azure extrapolates the complexity of managing the hardware and infrastructure that allows your code to execute. That extrapolation allows you the developer to focus on the functionality of your code, not the details of how you’re going to deploy it. Note: There are obviously going to be limitations and you should make sure you understand them so you’re not blindsided. The way that most people talk about these functions is to discuss implementing one individual function and how to go about doing that. [Continue Reading]

Introduction When I last left you (in Part 3) we had completed the round-trip journey that is learning all the facets to accessing the Microsoft Graph API (MSGraph) through an Azure Application and the ADAL.js library. A significant portion of our time was spent simply on the different ways to leverage ADAL.js depending on the framework you were using. In this next installment we’re going to go one step further and streamline our implementation of ADAL, in AngularJS specifically, but with broader implications to any web based framework. [Continue Reading]

It’s a great privilege and great fun to work with the exceptional team at Shire now part of Takeda that’s building a bleeding edge intranet to support their now 24,000 employees and growing. The team is exploring some very new territory and learning a lot along the way. During last weeks webinar, Microsoft’s Mark Kashman promised we’d post some of the lessons learned in the project. It’s my pleasure to share with the greater world a tidbit of that knowledge in the form of how to create a property pane for an individual item, not just the web part using the SharePoint Framework (SPFx). Bob German has also done several blog posts on the lessons learned, you can start reading them at Bob German’s Vantage Point. [Continue Reading]

The requirement seemed deceptively simple… and it was, somewhat… simple. I’ll start with showing you how very simple it is to launch a Microsoft Flow (“flow”) from your client-side code hosted, well… wherever. I will give you this caveat, launching a flow this way requires no authentication. The URL is entirely obscure, but if you’re concerned that the flow you’re starting does something you only want to allow authenticated users in your organization to do then you may want to rethink this. As with all security issue you need to assess and balance security with risk. I suppose that’s true of life too. [Continue Reading]

One of the great joys of developing custom forms in SharePoint is developing the controls for some of the more complicated field types, specifically the Taxonomy Picker and the People Picker. If you’re sensing sarcasm, you would be correct. There are brave souls out there who recreated these components for us that utilize no less than five (and sometimes more) Microsoft Javascript libraries. The reality is, for the People Picker, which is what I’m going to be discussing today, you’re really looking for a type ahead input field that filters a list of people that you can retrieve from SharePoint. Sounds easy right… *sigh* if only. [Continue Reading]

If you develop client side solutions for SharePoint you’ve either run into this or you will run into the following scenario. SharePoint stores all its date/time fields in UTC time. The site collections, sites, and the users, can have their own time zone settings. If you’re using SharePoint out of the box because all the content is rendered on the server and pushed to the client with all the date/time translation has been done for you. This makes wonderful sense, except when you try and write JavaScript against those same data points. The REST endpoints that return the data for you give you the date string in a format that is specific to the regional settings of the person asking for them. Sadly, this doesn’t translate as well to JavaScript as you might like. I’ve set up a scenario to illustrate the point with a couple of manipulations you can make depending on your desired goals. [Continue Reading]

Yesterday was a huge day for me professionally as I was awarded my first (and hopefully not last) Microsoft MVP Award. It was such a huge honor, and I felt it appropriate to give a shout out here to the Microsoft community for their support. There have been so many great mentors in my life over the years, many of whom I still collaborate with on a regular (if not daily) basis. Everyone that I interact with has been so supportive in helping me find my way whether it be technically or “socially”, and I hope I have often been able to reciprocate in kind. So, thank you to everyone I interact with in the community for being so open and generous with your knowledge and time! It’s been a whirlwind year for me, as the date of March 1, also marks a year since I first started talking to Marc about the possibility of joining him at Sympraxis Consulting. What felt like a huge decision was probably the best one I’ve ever made. He’s been a great mentor as I embarked on taking what I always did quietly behind the scenes out into the community. This last year has seen me do things many who’ve known me were somewhat shocked by… helping organize the Granite State SharePoint User Group, blogging more, speaking at conferences (this was the big one), and then connecting with various colleagues of Marc’s (and now of mine), in the MVP community. So, also, a special thank you to him, as I absolutely couldn’t have done it without him. I hope this marks only the beginning of this new-ish phase of my professional life, thanks again! [Continue Reading]