Latest Server 2016 topics

For this last post I want to take what we’ve learned and add the final pieces that have you creating web parts in the same way you would modern SPFx web parts and solutions. We’re going to start by discussing TypeScript and then briefly touch on Sass and how to include these languages into your new Webpack/Gulp environment. TypeScript is becoming almost ubiquitous in modern web development. The pros are numerous, my favorites are the ability to write code to target older browser with modern capabilities, and the ability to use a version of intellisense to validate your objects properties and methods. In my experience both of these features makes development go faster. The cons are that you’ll need to transpile your code as well as utilize typings for the libraries you want to include. By using Visual Studio Code, or another IDE as your development environment TypeScript is pretty much built in. If you are coming from C#, or some other compiled language, you’re going to find that you feel significantly more comfortable writing TypeScript than JavaScript, mainly because many of the conventions you’re used to have an equivalent in the TypeScript language and thus patterns like MVVM are easily implemented. [Continue Reading]

In our last post I went through the gulp process we were implementing to watch our files and upload them into an appropriate SharePoint library so that we can test our work inside SharePoint regardless of if SharePoint was version 2007 or SharePoint Online. Now we’re going to take things further and formalize our process. One of the tools the SharePoint Framework (SPFx) uses is Webpack. Webpack’s main goal is to take the many files that you create as a developer and bundle them all together into one JavaScript file. The benefit of bundling is that we make one call to one file instead of multiple calls for many files which is more efficient (in general). What it also does is simplify the maintenance of your JavaScript references because instead of having 10’s of files you end up with as little as 1 file. [Continue Reading]

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]

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]

A quick post today to augment what’s out there in the “Googleverse”. I needed to create a Document Set in client side code, and went out to find the appropriate calls to make that happen. To update the metadata on the folder you create (which is all a Document Set really is under the covers), you simply make an “almost” normal list item update call. So the following is the various “functions” you need and how to string them together to do this task. As you read through, I’ll point out in the code where other older posts on this topic steer you wrong. [Continue Reading]

I’m constantly trying to remember which way to encode content when making calls to the server while developing client side solutions for SharePoint. Usually it’s some form of JavaScript’s encodeURI()/encodeURIComponent() functions… but this latest one gave me a bit of trouble until I finally figured it out which encoding to use and, almost as important, when to apply it. When making RESTful calls to update or create data in a SharePoint list you must include the “__metadata” (two underscores followed by ‘metadata’) property in the information object you send on the data property of the call. If you have a list with the internal name “Clients” and your data property object is called “item” then you would do something like the following: [Continue Reading]

Centralizing your SharePoint client side code “Code Creep”… no it’s not the latest thriller movie out of Hollywood, although it probably could be. I’m referring to the sprawl of client side code files that are stored when implementing client side web parts or “widgets” in SharePoint. A common solution for implementing “widgets” in SharePoint is to store the files in a document library, linking to them with a CEWP that will then run and render your “widget”. This is an effective way to implement customization when you don’t have administrator access, or you’re running in SharePoint online, or you just prefer the flexibility of a client side development paradigm; as some of my colleagues in the SharePoint community like to say, “It isn’t code, it’s content.” However, depending on the complexities of your environment and your development staff, this kind of end run can cause maintenance issues at best, horror stories at worst. There are many ways to solve the code creep problem, from simple to incredibly complicated, and of course, as with everything there is no one-size-fits-all answer. Some guidance from my perspective centers on where your code will be implemented and how big your farm/tenant(s) are. I’ve created a matrix below that outlines my thoughts on the subject. [Continue Reading]

This content has also been posted on Bob German's Vantage Point. Widget Wrangler Webcast and New Release Here’s a quick update on the Widget Wrangler – the light-weight JavaScript framework that helps you build flexible widgets that can be used in SharePoint content editor web parts, add-in parts, or really pretty much everywhere. The Widget Wrangler was featured in a webcast on Channel 9 today (Video has been removed). The Office team’s Vesa Juvonen interviewed WW creators Julie Turner and Bob German, who explained the framework and demonstrated how to use it with AngularJS, jQuery, and plain old JavaScript. [Continue Reading]