Category: programming

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.

I’ve been learning a lot while working on my current SharePoint project. There’s been a lot of “trial and error” stuff, where I try something, get an error message, Google the message, then spend an hour or two puzzling out what I did wrong.

Today’s issue was related to the default 5000-item list view threshold. I was already aware that it existed, and that I’d need to take certain measures to avoid bumping up against it. The main list for my project is going to have about 20,000 items in it, when it’s in production, so I knew I had to watch out for it.

The list has two fields, company and vendor number, that, combined, form a unique key. In SQL, I would put them together into a single two-field unique index, and that would be sufficient to allow lookups to work well. In SharePoint, it’s a little more complicated. It’s theoretically possible to create a two-column compound index, but I can’t do that on my list, for some reason. (At some point, I’ll have to do some research and figure out why.) So I’ve got two single-column indexes.

One of the things I need to do in my code is pull up a single record from my list, given company and vendor number. I’m using something like the code below to do that. (This is CSOM code.) This code should only ever return a single record, since the combination of the two fields is always unique, and they’re both always specified.

The original version of this code had the ‘CompanyName’ field first, and the ‘VendorNo’ field second. That version caused a crash with the message “The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator.” That didn’t make any sense to me, since I was specifying values for both indexed fields, and the result should have always been zero or one records.

Some background first: The distribution of the data in my list is a bit lopsided. There are about a half-dozen company codes, and about 6000 unique vendor numbers. There are more than 5000 vendor numbers in the main company and less than 5000 in the others. In SQL, this wouldn’t matter much. Any query with “where VendorNo=x and CompanyName=y” would work fine, regardless of the ordering of the ‘where’ clause.

In CAML, I’m guessing, the order of fields in the ‘where’ clause DOES matter. My guess is that, with the ‘CompanyName’ field first, SharePoint was first doing a select of all items with ‘CompanyName=x’, which in some cases would return more than 5000 rows. Hence the error. By switching the order, it’s searching on ‘VendorNo’ first, which is never going to return more than a half-dozen items (one for each company, if the vendor exists in all of them). Then, it does a secondary query on the CompanyName which whittles down the result set to 0 or 1 records. I’m not entirely sure if I’ve got this right, but I do know that switching the order of the fields in the CAML fixed things.

So, lesson learned: SharePoint isn’t nearly as smart as SQL Server about query optimization.

Another side-lesson I learned: I initially didn’t have my CAML query specified quite right. (I was missing the “<View><Query>” part.) This did NOT result in an error from SharePoint. Rather, it resulted in the query returning ALL records in the list. (It took a while to figure that out.)

I suspect that I’m going to learn even more lessons about SharePoint’s quirks as I get deeper into the testing phase on this project.

Useful Links:

• Creating Performant SharePoint apps with Large Lists
• Resolving the List View Threshold when Migrating to O365
• Demystifying The SharePoint Lists Threshold
• Query Throttling and Indexing
• Manage lists and libraries with many items