Category: SharePoint

I got a chance to work on another TypeScript / SharePoint project at work recently. I’m finding these projects to be a nice change of pace from my usual Dynamics AX work.

I’m not doing anything that’s much more complicated than I did on the last one, but I got a little more ambitious on this one. I’m still using Q for promises and Papa Parse for parsing an input CSV file. I think I’m getting a little better with promises, but I still occasionally have problems with them.

On my last project, I put all my TypeScript code in one file. For this one, I’ve broken things up into several classes and files. I’ve even gone as far as having an abstract base class with two child classes inheriting from it.

And, for the last project, I just deployed the generated JavaScript as-is. For this one, I’m using Web Essentials to combine and minify the JavaScript. That’s working better than I thought it would.

I’ve also given up on the idea of deploying this thing as a regular SharePoint sandbox project, though I’ve set it up that way in Visual Studio. Instead, I’m simply copying the HTML and JS files to the SharePoint server with SharePoint Designer. Maybe that’s not the best way to do it, but it’s the easiest, and the least disruptive to the server. (I should look into whether or not it’s possible for me to do that with PowerShell.)

I’m only just starting to learn JSOM (after previously learning the server-side object model, and CSOM, via C#). There are some slightly weird requirements and limitations that are constantly tripping me up. Here’s today’s waste of time: trying to get the current site’s master page URL.

Here’s what I came up with:

$(document).ready(function () {
            $('#divMain').text('Hello World.');
            getMasterUrl();
        });
        function getMasterUrl() {
            var myCtx = new SP.ClientContext();
            this.site = myCtx.get_site();
            this.web = myCtx.get_web();
            myCtx.load(web);
            myCtx.executeQueryAsync(
                Function.createDelegate(this, this.onSucceededMasterUrl),
                Function.createDelegate(this, this.onFailed)
                );
        }

        function onSucceededMasterUrl() {
            $('#divMain').text('Master URL: ' + web.get_masterUrl());
        }
        function onFailed(sender, args) {
            $('#divMain').text('Failed: ' + args.get_message());
        }

This just kept failing. I tried a bunch of random stuff to get it to work. In the end, I made a fairly minor change that got it to work. But then, I changed the code back, and it still worked. So this was going to be a post about a minor quirk of JSOM, but now it’s more of a “WTF” post. I’m sure I did something to make it work, and I just lost track of what it was. Well, either way, I’m having some fun with JavaScript.

I’m just about finished with the SharePoint project that I’ve been working on for the last few months. One requirement for the project was to allow arbitrary “comments” on the main documents for the project. There are some built-in ways to accommodate comments in SharePoint, but I gave up on those after experimenting a bit. Instead, I created a new list that would act as a child table to my main list, in a simple one-to-many relationship. And I decided to use plain text (rather than rich text) for the comment field itself.

I’ve had problems with SharePoint rich text fields in the past, and I wanted to put some constraints on the users, so they wouldn’t go nuts with the vast array of bad things rich text fields in SharePoint let you do. And I didn’t see any reason why plain text wouldn’t be “good enough” for this particular case. However, for this application, a lot of URLs and email addresses are going to get posted in comments, and I wanted to be able to “linkify” them. I almost wrote my own code for that, but then found the SPUtility.AutoHyperlinking method. It works pretty well, and also translates quotes, angle brackets, and other possibly confusing characters into their corresponding HTML entity codes.

I also got a little interested in the idea of supporting some limited formatting (like bold, italic, etc.) without going full-on rich text. My first thought on that was to look into the SharePoint wiki functionality. I was hoping for a function like SPUtility.AutoHyperlinking, but which would convert some simple wiki markup into HTML. But SharePoint’s wiki capabilities are limited, and really only support links.

So I then gave Markdown some thought. There’s obviously no built-in support for Markdown in SharePoint, but I figured that I could find a .NET library that would let me handle the MD to HTML conversion on the back-end. There are, indeed, several libraries available for Markdown conversion. I found two that stood out as probably the best, for my use:

• CommonMark.NET is a pretty popular one that’s been around for a while.
• Markdig looks like it’s probably newer and slightly less popular than CommonMark.NET, but it has some interesting extensions, including an auto-linking extension that would have been useful for me.

In the end, I decided that it was pretty unlikely that the user base for this project would embrace anything as nerdy as Markdown, so I didn’t bother adding it to the project. But I had some fun messing around with it.

And I should mention that I figured out, at some point, that SharePoint 2013 supports two levels of rich-text: one that is the “full” rich text mode, allowing pretty much anything and everything, and one that is limited to a pretty reasonable subset (bold, italic, text alignment, links, and stuff like that). In retrospect, I probably should have gone with the limited rich-text, though even that might have caused unexpected issues. (I have learned to trust SharePoint only as far as I can throw the server on which it’s running…)

I hit another weird little problem on my SharePoint project today. This one’s a bit different from the previous ones I’ve blogged about recently. A key point to start: I’m developing my solution on a VM running Windows Server 2012 R2. But the end-users are all using Windows 7.

I have one big detail page for this  project that’s got a lot of information on it. It’s a regular Web Forms ASP.NET page, in a SharePoint farm solution. I’ve tried to get everything on the page looking reasonably nice, while staying within the default look and feel of SharePoint 2013. So I’ve just got some CSS tweaks to get everything laid out right and looking good. And the page does look reasonably good on my dev VM. But I’ve noticed that certain text looks pretty bad when viewed on a Windows 7 machine.

The default font in SharePoint 2013, for most stuff, is something called “Segoe UI Light”. This is a Microsoft font that they, apparently, use for a lot of internal stuff. If you look at this page, you’ll see something interesting: Windows 7 uses version 5.00 of the font, while Windows 8 uses version 5.27. Checking my desktop Win 7 PC, I can see that it is indeed on version 5.00. (And I have version 5.36 on my Win 2012 R2 VM.)

This blog post goes into the differences between these font versions in a bit more detail. Here’s the one line that really caught my attention: “Microsoft’s fonts team has also worked on improving the hinting of Segoe UI, especially the Light variant which was never properly hinted.” So, yeah, that “never properly hinted” thing is probably why my page title looks horrible on Windows 7.

I don’t want it to sound like I’m bashing Microsoft’s font too much. It’s actually pretty nice, especially if you have a recent version on your PC and not the 5.00 version. But, for my project, it’s a problem. So I looked into switching to a Google web font. I choose Open Sans as a replacement for Segoe UI. I’d seen it suggested somewhere, and it seems to work well, and is free to use.

I’ve used Google fonts before, but had forgotten how to use them. It’s pretty easy. Just Put this in your page head:
<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet">

And use this for your CSS:
font-family: 'Open Sans', sans-serif;

This has worked out pretty well for me. The page now looks good on Windows 7 and on more recent versions.

Here’s a quick follow-up to my previous post on dealing with SharePoint list view thresholds. I just bumped up against another case where I had to change some code to deal with it.

To recap the project a bit, I am writing a console app that will import a bunch of data into a SharePoint site. Since I’m human, and I make mistakes, the first step of this importer is to delete any existing data in those lists (which would be leftover from the previous test run).

I had a simple solution for doing that, deleting records in batches of 100, based somewhat on this example. I assumed that would work OK, even with larger lists, but I didn’t take into account that the first step in my process was to get all items in the list. That, of course, fails for a very large list. So I had to change my code to initially get only the first 4000 records in the list. (That can be done with the RowLimit clause in CAML.) Then, I delete from that subset in batches of 100. Then, I just repeat that until there are no more records left.

As far as I can tell, there’s no SharePoint CSOM equivalent to SQL’s “truncate table”, which would have made this much easier. And I feel like I’m probably still not doing this in the most efficient way. If I was creating a process that needed to do this repeatedly, instead of just a few times, I’d dig into it some more. And if I was retrieving items instead of deleting them, I’d probably do something with ListItemCollectionPosition.